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process  of  analyzing  the  program.  It  provides  automated  coordination  between  the  tools 
and  as  such  maintains  a  certain  level  of  abstraction  for  the  analyst.  It  allows  for  rapid 
and  customized  improvement  in  the  automation  of  the  analysis  process. 

The  thesis  discusses  the  background  involved  in  testing  tools,  user  interfaces,  and 
the  combination  of  the  two  into  a  useful  tool.  An  implemented  prototype  is  discussed 
and  an  example  of  failure  region  analysis  performed  with  the  graphical  user  interface  is 
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I.  INTRODUCTION 


Research  in  software  system  development  continues  to  search  for  methods  to 
improve  the  quality  and  reliability  of  systems  at  reduced  cost.  Software  continues  to  be 
the  major  cost  aspect  in  total  system  development.  Large  systems  consist  of  many 
components  with  complicated  interactions.  The  focus  of  testing  is  to  prevent  bugs  or, 
if  it  cannot  prevent  bugs,  to  detect  them  in  software.  (Beizer,  1983,  pp.  1,  3)  The  size 
and  complexity  of  large  software  systems  make  thorough  testing  difficult.  Software 
system  failures  continue  to  surface  in  some  of  the  most  thoroughly  tested  systems  in  the 
world  like  those  at  AT&T  and  NASA. 

Software  testing  tools  in  themselves  are  a  recent  development  in  the  life  time  of 
computers  and  programs.  The  future  of  software  engineering  is  an  integrated 
environment  containing  all  the  development  and  testing  tools  necessary  for  software 
engineers  to  produce  reliable,  efficient,  and  cost-effective  software.  These  types  of 
environments,  on  the  development  side  of  software  engineering,  have  become 
synonymous  with  the  term  CASE.  Most  CASE  texts  don’t  cover  the  testing  side  of  the 
development  project.  Fisher  talks  about  "stress  testing"  on  a  system,  using  a  testing 
harness  to  test  individual  modules.  Separate  quality  assurance  groups  (the  testers)  usually 
build  these  test  harnesses.  (Fisher,  1988,  p.  48)  Few  authors  of  CASE  tools  address  the 
complete  software  testing  package  needed  to  validate  thoroughly  future  large  scale 
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projects.  Even  code  generated  via  future  specification  languages  will  still  need  thorough 
testing,  to  ensure  that  the  specified  system  meets  operational  needs. 

Unfortunately  software  testers  have  a  long  way  to  go  before  they  can  realize  this 
dream.  Adrion,  Branstad,  and  Chemiavsky  reported  in  June  1982  that  of  the  methods 
used  to  test  software  systems,  "the  most  successful  have  been  the  disciplined  manual 
techniques,  such  as  walk-throughs,  reviews,  and  inspections,  applied  to  all  stages  in  the 
life  cycle."  (Adrion,  Branstad  and  Chemiavsky,  1982)  Their  observations  are  still  true 
today.  The  human  mind  is  flexible,  adaptable,  portable  and  robust  when  analyzing  code. 
It  works  well  for  small  systems.  For  large  systems,  with  their  attendant  large  amount 
of  detail  affecting  reliability,  only  automation  will  make  thorough  testing  feasible, 
practical,  efficient  and  cost-effective. 

Automation  requires  formalization  of  development  and  design  of  software.  But  in 
testing  there  has  been  little  progress  toward  developing  a  theoretical  basis  from  which 
to  relate  software  behavior  to  validation  and  verification.  (Adrion,  Branstad  and 
Chemiavsky,  1982)  This  lack  of  a  sound  theoretical  foundation  is  a  problem  with  which 
researchers  continue  to  struggle. 

A.  TOOL  TAXONOMIES 

Before  examining  any  specific  tool  or  environment  now  available,  a  brief  look  at 
a  taxonomy  of  automated  tools  is  in  order.  Ramamoorthy  and  Ho  broadly  classify 
automated  tools  under  three  groups:  operational  mode,  application,  or  function.  The 
operational  mode  grouping  partitions  tools  into  static  or  dynamic  analysis  methods. 
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Static  analysis  analyzes  the  logic  and  structure  of  a  program  without  running  the 
program,  and  looks  for  properties  determinable  from  the  source  code  alone.  Dynamic 
analysis  requires  the  tester  to  execute  the  program,  observe  its  behavior,  and  look  for 
runtime  properties. 

The  application  grouping  partitions  tools  by  their  use  in  a  specific  phase  of 
development.  These  tools  should  span  the  entire  spectrum  of  the  software  development 
cycle  when  used  correctly.  A  software  development  system  might  include  tools  for 
design  analysis,  debugging,  testing  and  partial  validation. 

The  functional  classification  partitions  tools  by  their  specific  functions.  For 
example,  static  analysis  tools  would  include:  code  analysis,  program  structure  checks 
and  module  interface  checks.  Code  analysis  tools  perform  syntax  analysis  on  the  source 
code,  extracting  information  used  to  find  error  prone  constructions,  and  module 
relationships.  For  instance,  a  compiler  is  a  complex  example  of  a  code  analysis  tool. 
(Ramamoorthy  and  Ho,  1975)  Program  structure  analysis  tools  are  essential  for  software 
validation.  This  analysis  technique  often  includes  program  graph  generation,  modelling 
a  program  as  a  directed  graph  with  nodes  representing  the  flow  of  control. 

Code  analysis  and  structure  analysis  are  module  tests  that  analyze  the  active 
module.  Module  interface  tools  look  for  various  anomalies  across  module  boundaries 
and  are  global  checks.  (Ramamoorthy  and  Ho,  1975) 

Dynamic  analysis  tools  might  include:  runtime  behavior  monitors  and  test  case 
generation.  Testing  tools  that  monitor  a  program’s  runtime  behavior  can  trace  a  variable 
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throughout  the  execution  of  the  program,  or  record  paths  executed  by  particular  test 


cases. 


B.  TYPES  OF  TESTING 

Functional  testing  views  the  program  or  system  as  a  black  box.  Functional  testing 
provides  inputs  to  the  program  or  system,  and  verifies  the  outputs  for  conformance  to 
preset  objectives.  Functional  testing  normally  takes  the  user’s  point  of  view.  Structural 
testing,  on  the  other  hand,  deals  with  the  implementation  details  of  the  program  or 
system.  Included  in  the  considerations  are  the  style  of  programming,  the  source 
language,  and  the  coding  details.  The  boundary  between  the  two  is  fuzzy,  and  the  user 
will  see  only  the  outermost  layer.  (Beizer,  1983,  pp.  4-5) 

Since  exhaustive  testing  is  impractical,  Ramamoorthy  and  Ho  define  "complete" 
testing  in  more  relaxed  terms.  For  example,  one  might  consider  a  program  "tested"  if 
all  executable  statements  execute  at  least  once.  This  is  just  one  possible  definition  of 
complete  testing.  Different  testers  may  find  their  own  definitions  of  necessary  and 
sufficient  test  cases.  Automation  suits  complete  testing. 

Formal  proofs  of  correctness  rely  on  both  functional  and  structural  concepts.  A 
formal  language  describes  the  requirements,  and  an  inductive  proof  uses  each  statement 
to  show  that  all  possible  input  sequences  will  produce  correct  output.  These  proofs  are 
very  expensive,  and  normally  limited  to  programs  like  a  security  kernel  for  a  system  or 
other  crucial  software.  (Beizer,  1983,  p.  14)  At  present,  a  formal  proof  of  program 
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correctness  is  infeasible  for  large  systems.  A  program  in  Algol  with  433  statements 
required  46  pages  of  proofs.  (Ramamoorthy  and  Ho,  1975) 

Structural  and  functional  testing  are  not  contradictory  ideas.  There  is  a  time  and 
place  for  use  of  each.  Both  methods  are  effective,  though  each  has  certain  limitations. 
In  general,  system  testing  is  functional,  while  unit  testing  is  structural  in  nature.  In 
principle,  a  functional  test  could  detect  all  bugs  in  a  program,  but  it  would  require  an 
impractical  amount  of  time.  On  the  other  hand,  while  structural  tests  are  finite  they 
cannot  detect  all  bugs  even  if  executed  to  completion.  (Beizer,  1984,  p.  8) 

To  have  a  complete  functional  test,  input  r.:ust  include  all  possible  input  streams. 
In  each  case,  the  program  would  either  accept  or  reject  the  input  stream.  If  the  program 
accepts  the  stream,  it  either  produce  a  correct  output  or  an  incorrect  output.  If  the 
program  rejects  the  stream,  it  should  produce  an  output  showing  the  rejection,  so  in 
;very  possible  case  there  would  be  some  sort  of  output.  (Beizer,  1983,  p.  13)  A 
command  line  interface  would  suffice  in  this  particular  set  of  testing,  as  the  user  could 
enter  data  from  the  keyboard  or  from  an  input  file.  A  way  to  capture  the  output  would 
be  necessary  in  order  to  provide  the  capability  of  running  several  input  streams  at  once, 
and  then  evaluating  the  results  later. 

Debugging  tracers  are  dynamic  software  tools  that  tell  the  user  what  happened 
during  a  particular  run  of  the  program.  When  debugging  tracers  use  a  certain  set  of 
input  data,  they  can  show  what  parts  of  the  program  execute  in  what  order.  There  has 
been  much  development  in  this  area,  and  most  mainframe  compilers  are  capable  of 
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supplying  runtime  traces  at  varying  degrees  of  sophistication.  At  times  the  process  of 
debugging  is  so  difficult,  the  programmer  welcomes  any  assistance.  (Green,  1981) 

The  use  of  path  testing  is  the  cornerstone  of  all  testing.  It  focuses  on  the  control 
structures  of  a  program.  For  our  purposes,  a  path  is  any  executable  sequence  of 
instructions  or  statements  that  go  through  a  routine.  To  be  more  specific,  the  path  will 
start  at  a  junction  (the  program  entrance  or  designated  statement)  and  proceed  until  it 
reaches  another  junction  (the  program  exit  or  designated  statement).  The  goal  is  to  show 
that  the  actual  behavior  of  the  routine  matches  its  intended  behavior.  Testers  show  this 
by  exercising  multiple  paths,  but  in  practice  the  number  of  paths  is  often  infinite.  Each 
decision  doubles  the  numbers  of  paths,  each  case  statement  multiplies  the  number  of 
paths  by  the  number  of  cases,  and  each  loop  has  a  potentially  infinite  number  of  cases. 
So  achieving  absolute  assurance  is  not  only  unrealistic  but  unachievable  as  well. 
Therefore,  path  testing  is  accomplished  over  a  smaller  set  of  paths,  carefully  selected  so 
they  meet  the  above  stated  goal.  If  unable  to  accomplish  that,  they  should  at  least  catch 
most  bugs  a  unit-level  test  would  catch.  (Beizer,  1984,  pp.  37  -  38) 

Selective  testing  exercises  a  program  with  data  prepared  by  the  programmers. 
Because  the  programmers  prepare  the  data  to  test  their  own  code,  they  unavoidably  bias 
the  set  of  test  inputs. 

Exhaustive  testing  requires  the  tester  to  execute  every  executable  path  at  least  once. 
Exhaustive  testing  is  impractical  and  unrealizable  usually  because  of  the  enormous 
number  of  paths  requiring  execution.  The  number  of  executable  paths  grows 
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exponentially  and  testing  them  even  for  small  programs  would  exceed  the  lifetime  of 
most  testers. 

Each  path  will  have  associated  with  it  the  inputs  that  force  the  execution  of  that 
particular  path  and  the  results  (outputs,  state  changes,  database  changes)  for  that  path. 
Tactics  should  include  sufficient  paths  for  coverage  of  the  routine/program  and  a 
selection  of  paths  that  are  short  and  functionally  sensible.  The  number  of  changes  from 
path  to  path  should  be  kept  to  a  minimum.  It  is  better  to  use  a  greater  number  of  simple 
paths  than  a  small  number  of  complex  paths.  (Beizer,  1984,  p.  41) 

One  way  to  obtain  path  confidence  is  with  instrumentation,  the  simplest  of  which 
is  running  the  routine  under  a  trace.  We  encounter  several  problems  with  this  scenario: 

•  A  typical  trace  produces  voluminous  output.  The  tester  gets  more  data  than  he 
wanted.  (Beizer,  1984,  p.  47)  Studying  the  source  listing  simplifies  the  process 
of  analyzing  this  data  and  determining  an  answer  to  a  given  question.  (Green, 
1981) 

•  Traces  involve  a  very  high  overhead,  which  may  destroy  timing  relations  in  the 
program.  Interrupt  handlers,  device  handlers,  communication  interfaces,  and  other 
such  routines  may  not  work  in  the  trace  mode. 

•  Because  a  trace  may  change  location  dependencies,  bugs  may  exist  when  the 
program  runs  without  the  trace  and  disappear  with  a  trace.  (Beizer,  1984,  p.  47) 

•  These  programs  are  usually  not  interactive.  (Green,  1981) 

A  recent  development  in  software  testing  is  the  study  of  failure  region  analysis. 
This  is  the  study  of  errors  occurring  in  proximity  to  other  errors,  which  Myers  referred 
to  as  error  clustering.  Ammann  and  Knight  described  this  error  clustering  as  "failure 
regions."  (Bolchoz,  1990,  p.  3) 
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A  failure  region  is  a  region  of  a  program’s  input  space,  mapped  by  faults  in  the 
program’s  source  code,  to  failures  in  the  output  space.  The  purpose  of  failure  region 
analysis  is  to  improve  testing  efficiency  by  reducing  the  number  of  redundant  initial  tests, 
preventing  redundant  multiple  error  detection.  Failure  region  testing  may  also  act  as  a 
guide  for  later  regression  testing. 

Upon  isolating  a  failure  region,  the  tester  can  omit  any  test  cases  that  fall  within 
that  region  from  the  testing  process  until  the  programmers  correct  the  fault. 
Programmers  correct  faults  by  changing  the  source  code.  The  tester  can  then  use  the 
failure  region  as  a  guide  for  testing  the  correctness  of  changes.  By  incorporating  failure 
region  testing  into  the  complete  testing  package,  testers  can  avoid  duplicating  test  cases 
and  proceed  on  to  as  yet  unexplored  test  cases.  In  this  way  testers  can  uncover  multiple 
errors  before  sending  a  program  back  to  the  programming  team  for  corrections. 

Inequalities  derived  from  the  combination  of  three  sources  bound  the  failure  region. 
Those  sources  are: 

•  The  reachability  condition  for  the  code  with  the  defect. 

•  The  conditions  under  which  the  calculations  in  that  defective  code  produce  an 

erroneous  result. 

•  The  conditions  in  which  later  process  does  not  mask  the  erroneous  value 

Research  efforts  are  underway  to  automate  the  failure  region  analysis  process.  The 
motivation  for  this  thesis  is  the  research  effort  to  integrate  these  automated  failure  region 
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tools  into  a  graphical  user  interface.  Later  chapters  discuss  the  tools  and  e*  vironinent 
in  more  detail. 

C.  ENVIRONMENT  OF  TESTING  TOOLS 

Future  program  development  environments  will  provide  the  tester  with  many  tools 
designed  to  ease  the  program  testing  process.  These  include  lexical  analyzers,  dataflow 
analyzers,  automated  instrumentation,  smart  compilers,  automated  test  data  selection,  and 
knowledge-based  program  testing  aides.  This  is  a  relatively  new  area  of  research  and 
new  software  testing  technology  will  lead  to  new  testing  tools. 

During  the  early  70’ s  reliability  and  quality-assurance  concerns  in  software 
engineering  gave  rise  to  systematic  testing  procedures,  notations  of  formal  program 
correctness,  and  models  of  fault  tolerance  and  total  system  reliability.  Analysis  of  actual 
allocation  of  development  effort  and  expense  appeared.  The  80’s  saw  the  rise  of  CASE, 
with  the  development  of  automated  tools  corresponding  to  each  phase  of  the  software  life 
cycle,  appearing  on  stand  alone  workstations.  In  the  area  of  software  testing  tools,  there 
are  few  articles  addressing  how  to  set  the  foundation  for  these  types  of  environments  to 
enable  testers  to  add/delete  tools  to/from  the  environment  at  arbitrary  points  in  time. 
(Lewis  and  Oman,  1990) 

This  critical  part  of  the  software  life  cycle  must  continue  to  evolve.  Part  of  this 
evolution  is  the  recent  emphasis  on  human-computer  interaction.  A  survey  of  15 
representatives  of  industry  and  academia  revealed  that  the  pervasiveness  of  graphical  user 
interfaces,  including  speech  and  other  ways  to  interact  with  a  computer  is  a  clear  sign 
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that  all  software  of  the  future  must  address  the  users’  needs  for  ease  of  use.  The 


designers  of  a  software  testing  tool  support  environment  must  consider  the  needs,  desires 
and  frustration  of  the  individual  tester.  As  simple  as  it  sounds,  the  environment  should 
provide  the  tester  with  information  that  helps  analyze  the  program.  Many  tools  now 
available  output  large  amounts  of  confusing  data  with  little  real  analytical  value.  The 
environment  designer  should  try  to  help  the  tester  focus  on  what  is  important,  and 
remove  as  much  ambiguity  from  the  analysis  as  possible.  (Lewis  and  Oman,  1990) 

D.  INTERFACE  DESIGN 

Most  testing  tools  are  research  efforts,  and  give  little  consideration  to  the  interface 
design.  This  makes  them  difficult  to  use.  Tool  environments  should  use  current 
interface  technology  so  users  won’t  have  to  rely  on  short  term  memory  to  use  the  system. 
The  system  should  supply  all  the  support  and  documentation  users  need. 

The  interest  in  designing  "good"  user  interfaces  has  grown  in  recent  years,  as 
computers  must  serve  a  more  diverse  group  of  people  with  varying  technical  expertise. 
Before  the  proliferation  of  personal  computers,  there  were  custom-built  programs  and 
personnel  specially  trained  to  use  them.  It  was  easier  to  train  the  few  users  than  to  build 
software  that  worked  naturally  with  the  user.  Now  user  interface  quality  has  become  a 
primary  issue,  and  phrases  like  "user-friendly"  are  everyday  language.  (Brown  and 
Cunningham,  1989,  p.  1) 

Human-computer  interaction  software  is  a  challenging  endeavor.  There  are  three 
developments  that  have  altered  this  field.  First,  there  now  exist  powerful  workstations 
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with  bitmapped  screens  and  pointing  devices.  These  provide  the  technological  base  for 
the  design  of  the  interface.  The  computer’s  interactive  capabilities  have  drawn  attention 
as  applications  have  become  increasingly  innovative.  Last,  because  today’s  software  is 
becoming  more  complex,  the  ability  to  communicate  better  with  the  computer  is  no 
longer  just  a  luxury;  it  is  a  necessity.  (Fischer,  1989) 

In  writing  human-computer  interface  software,  we  must  begin  with  the  human  as 
the  fixed  point.  We  must  distinguish  between  what  the  computer  will  do  and  what  the 
human  will  and  can  do.  During  this  process  the  designer  will  make  assumptions  about 
what  the  user  will  want  to  do.  While  making  these  assumptions,  the  designer  must 
remember  that  each  user  is  an  individual,  with  their  own  talents,  goals,  knowledge  and 
preferences.  (Fischer,  1989) 

How  do  people  process  various  sorts  of  information  displays?  How  do  they  use 
this  information  to  solve  problems?  The  study  of  human  factors  has  concerned  the 
physical  aspect  of  the  interface.  For  hardware,  this  has  produced  rules  saying  to  space 
and  align  the  knobs  properly  and  design  the  displays  and  workstation  layouts  based  upon 
the  idiosyncrasies  of  human  anatomy.  Researchers  have  labeled  this  area  of  research 
"cognitive  ergonomics".  Ergonomics  is  an  accepted  term  meaning  "the  study  of  the 
problems  of  people  in  adjusting  to  their  environment;  especially,  the  science  that  seeks 
to  adapt  work  or  working  conditions  to  suit  the  worker."  It  now  must  include  problem 
solving  and  the  analysis  of  information  displays.  (Curtis,  1981,  p.  1) 

Can  one  describe  what  makes  a  good  interface?  Every  user  of  a  computer  has  a 
different  idea  of  what  makes  a  "good"  user  interface.  Begin  with  the  definition  of  user 
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interface  -  it  is  not  simply  a  collection  of  code  objects.  A  user  interface  is  a  way  of 
ensuring  that  the  user  can  work  effectively  with  the  software.  (Brown  and  Cunningham, 
1989,  p.  1) 

A  user  interface  should  handle  all  input  and  output.  It  should  convey  all  the 
instructions  about  the  program’s  use,  and  allow  the  user  to  control  the  program  as 
naturally  as  possible.  The  interface  also  should  provide  the  program’s  results  to  the  user. 
(Brown  and  Cunningham,  1989,  p.  5) 

While  there  are  no  complete  human-computer  interface  theories,  researchers  have 
proposed  methods  and  principles.  (Fischer,  1989)  Shneiderman  postulates  eight  rules 
of  design  for  user  interfaces.  They  are: 

•  Strive  for  consistency. 

•  Enable  frequent  users  to  use  shortcuts. 

•  Offer  informative  feedback. 

•  Design  dialogues  to  yield  closure. 

•  Offer  simple  error  handling. 

•  Permit  easy  reversal  of  actions. 

•  Support  the  internal  locus  of  control. 

•  Reduce  short-term  memory  load.  (Shneiderman,  1987,  pp.  61  -  62) 

Now  an  examination  of  each  of  these  principles. 
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1.  Strive  for  consistency 

This  applies  to  single  actions  and  sequences  of  action,  and  may  involve 
prompts,  menus  and  help  screens.  Interfaces  should  keep  exceptions  to  a  minimum  and 
be  comprehensible  to  the  user.  (Shneiderman,  1987,  p.  61)  Consistency  is  the  mental 
model  the  user  has  of  a  particular  application.  It  is  the  way  in  which  the  user  controls 
the  application.  Besides  consistency,  the  interface  should  provide  some  flexibility  to  the 
user,  though  the  ideas  of  flexibility  and  consistency  are  not  without  some  contradiction. 
(Brown  and  Cunningham,  1989,  p.  9)  The  user  should  feel  comfortable  when  entering 
the  information,  for  an  awkward  input  design  is  very  noticeable.  (Brown  and 
Cunningham,  1989,  p.  15)  If  there  are  several  modes  available  within  the  single 
application,  consistency  becomes  more  difficult.  The  best  form  of  consistency  is  in  a 
modeless  application.  If  the  modeless  aspect  is  too  hard,  make  the  primary  application 
the  standard  mode,  so  the  exceptions  will  be  minimal.  (Brown  and  Cunningham,  1989, 
P-  23) 

2.  Enable  frequent  users  to  use  shortcuts 

As  the  user  gains  knowledge  of  the  program  or  system,  they  can  reduce  the 
interaction  with  the  interface,  and  increase  the  speed  of  the  interactions  that  remain.  A 
knowledgeable  user  will  want  special  keys,  abbreviations,  hidden  commands,  shorter 
response  times  and  faster  display  times.  (Shneiderman,  1987,  p.  61)  Humans  are  not 
static  beings.  Though  all  users  begin  as  novices,  and  some  may  remain  in  that 
classification,  they  also  may  progress  into  the  casual  or  expert  user  class.  (Fischer, 
1989)  The  options  for  input  are  recognition  memory  or  recall  memory.  If  both  options 
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are  available  to  the  user,  it  will  allow  for  greater  flexibility.  The  recognition  memory 
will  associate  the  command  choice  with  a  given  action,  as  in  a  menu.  For  the  more 
experienced  user,  the  command  line  options  rely  on  the  user’s  recall  memory.  (Brown 
and  Cunningham,  1989,  p.  22)  Command  systems  are  more  complex  than  menus, 
require  more  training  to  use  them,  and  require  the  user  to  possess  some  typing  skills. 
The  interface  requires  more  error  handling  capability,  since  input  is  unlimited. 
Command  line  interfaces  are  usually  fast  and  flexible,  and  preferred  by  an  expert  user 
when  they  require  speed  or  special  functions.  A  menu  system  limits  the  user  to  the 
choices  displayed  on  the  screen.  While  the  error  handling  need  not  be  as  intensive,  they 
are  usually  slower  and  less  flexible  than  the  command  line  mode.  (Brown  and 
Cunningham,  1989,  pp.  25  -  26) 

3.  Offer  informative  feedback 

Each  action  by  the  user  should  have  feedback  from  the  system.  The  level  of 
response  should  equate  to  the  action  performed.  A  visual  presentation  can  provide  an 
environment  for  showing  changes.  (Shneiderman,  1987,  p.  62)  Users  judge  new 
computer  systems  more  on  the  quality  of  their  communication  capabilities  than  on  then- 
processing  speed  and  their  memory  size.  The  human-computer  interfaces  of  the  future 
should  take  advantage  of  the  technology  now  available.  The  modem  workstations 
provide  many  possibilities,  yet  many  interfaces  are  still  command  line  oriented.  It  will 
take  an  effort  to  take  advantage  of  these  possibilities  in  the  design  of  future  software. 
(Fischer,  1989) 
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The  human-computer  interface  should  help  the  user  make  intelligent  choices.  In 
every  communication  there  is  a  speaker  and  a  listener  role.  The  speaker  presents 
information  and  the  listener  tries  to  understand  the  information.  The  listener  must  be  the 
more  intelligent  of  the  two,  because  he  must  not  only  understand  the  situation,  but  how 
the  speaker  presents  it.  In  a  human-computer  interface,  the  human  is  the  most  intelligent 
agent.  The  computer  should  provide  the  appropriate  cues  to  allow  the  user  to  choose  the 
next  step.  (Fischer,  1989) 

4.  Design  dialogues  to  yield  closure 

A  sequence  of  actions  should  consist  of  a  beginning,  a  middle  and  an  end. 
The  system  should  provide  informative  feedback  at  the  end  of  a  group  (closure).  The 
feedback  provided  can  give  the  user  a  feeling  of  accomplishment  or  relief,  and  suggesting 
that  they  may  prepare  for  the  next  sequence  of  actions.  (Shneiderman,  1987,  p.  62) 

5.  Offer  simple  error  handling 

The  system  should,  as  much  as  possible,  prevent  the  user  from  committing  an 
error.  When  an  error  occurs,  the  system  should  detect  the  error  and  offer  a  simple 
explanation  of  the  remedy,  or  use  simple  mechanisms  and  handle  the  error.  The  user 
should  only  have  to  correct  the  command,  not  reenter  it  completely.  Also,  the  program 
state  should  not  change  because  of  erroneous  commands.  (Shneiderman,  1987,  p.  62) 
Any  error  messages  should  have  enough  information  contained  in  them  that  the  user  feels 
comfortable  with  the  message,  and  understand  what  they  need  to  correct  the  condition. 
The  programmer  of  the  software  may  be  content  with  cryptic  messages,  but  the  normal 
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user  will  not  tolerate  wording  that  makes  them  feel  inadequate,  or  does  not  provide  the 
information  they  need  to  correct  the  error. 

6.  Permit  easy  reversal  of  actions 

While  it  is  sometimes  not  possible  to  reverse  every  action,  most  actions  should 
include  an  "undo"  option.  This  can  relieve  user  anxiety,  and  give  them  the  freedom  and 
flexibility  to  explore  new  portions  of  the  software  without  fear  of  committing  an 
irreversible  action.  (Shneiderman,  1987,  p.  62)  This  will  create  an  exploratory 
environment  for  the  human  user.  A  user  may  not  know  what  they  want  to  do,  while  the 
designer  of  the  human-computer  interface  may  not  understand  what  the  user  needs  or  will 
accept.  (Fischer,  1989) 

7.  Support  the  internal  locus  of  control 

Both  novice  and  experienced  users  prefer  to  feel  they  are  in  control  of  the 
system  and  it  is  responsive  to  their  actions.  The  user  should  be  the  initiator  of  the 
action,  and  the  system  the  responder.  (Shneiderman,  1987,  p.  62)  For  a  computer  to 
be  a  truly  useful  tool,  it  should  be  invisible  to  the  user  to  allow  them  to  concentrate  on 
their  problems  and  tasks.  (Fischer,  1989)  To  provide  comfortable  program  control,  the 
interface  needs  to  understand  the  audience  for  the  program.  The  designer  must  know 
how  the  program’s  intended  users  think  about  the  program’s  problem  and  how  they 
would  go  about  solving  it.  The  interface  should  provide  a  command  system  that  allows 
the  user  to  solve  the  problem  with  as  little  reference  to  the  computer  or  the  program  as 
possible.  (Brown  and  Cunningham,  1989,  p.  23) 
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8.  Reduce  short-term  memory  load 

The  human  information  processing  limit  of  "seven  plus  or  minus  two”  means 
displays  should  be  simple.  Designers  should  reduce  window  motion,  and  there  should 
be  adequate  training  time  for  codes  and  mnemonics.  They  should  provide  help  in  the 
form  of  on-line  access  to  syntax  forms,  abbreviations  and  code.  (Shneiderman,  1987, 
pp.  61  -  62)  Humans  have  some  limitations  the  human-computer  interface  design  should 
accommodate.  Humans  have  only  two  hands,  so  it  will  not  suffice  to  have  an  interface 
that  requires  two  hands  on  the  keyboard  while  concurrently  using  a  pointing  device  such 
as  a  mouse.  Humans  have  weaknesses  (limited  short  terr  .  memory  and  execution  errors) 
but  they  have  strengths  (powerful  information  processing  and  visual  systems).  Memory 
is  a  psychological  factor  of  the  human  mind.  There  is  a  difference  between  recall  and 
recognition  memory.  Command  line  interfaces  use  recall  memory,  while  a  menu  driven 
interface  uses  recognition  memory.  (Fischer,  1989)  Even  an  expert  user  will  have  times 
when  they  are  away  from  a  particular  application.  The  interface  can  assist  them  while 
they  are  returning  to  their  former  level  of  expertise. 

E.  TESTING  TOOLS 

The  basic  tool  for  the  programmer  performing  the  tests  is  a  description  of  the 
program.  This  may  be  a  listing  or  a  diagrammatic  representation.  (Brooke  and  Duncan, 
1981)  Is  it  always  true  that  a  diagrammatic  notation  will  be  easier  to  read  than  a 
conventional  one?  NO!  Some  diagrams  are  good,  while  others  are  not.  One  advantage 
is  that  it  is  easy  to  learn  the  conventions  used  in  the  design  of  a  diagram,  and  a  diagram 
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makes  an  excellent  communication  device  for  the  less  experienced  user.  The  designer 
must  have  the  right  image  of  the  user  before  using  the  diagrammatic  approach  to 
construct  the  user  interface.  (Fitter  and  Green,  1981) 

Computing  concerns  processes,  so  the  diagrams  would  need  to  be  able  to  explain 
processes.  Fitter  and  Green  propose  five  principles  for  the  development  of  diagrammatic 
notation.  The  information  represented  should 

•  be  relevant 

•  be  restricted  to  forms  that  are  comprehensible 

•  redundantly  recode  important  parts  of  the  program 

•  lcveal  underlying  processes  they  represent,  in  a  responsive  interactive  system 
allowing  manipulation  of  the  diagrams 

•  have  a  readily  revisable  notation.  (Fitter  and  Green,  1981) 

Designing  a  human-computer  interface  through  a  standard  programming  language 
forces  one  to  use  a  few  primitives  (read,  write,  format)  based  on  a  linear  stream,  vice 
a  two  dimensional  screen.  It  is  a  massive  undertaking  for  the  designer  to  build  the 
interface  from  low-level  components.  However,  there  are  environments  that  are 
functionally  rich  in  abstractions.  There  are  different  classes  of  windows,  screen  layout 
tools,  and  the  designer  may  reduce  the  size  of  the  application.  What  is  the  cost 
involved?  The  designer  must  learn  the  abstractions  and  understand  their  use,  but  this  is 
a  one-time  cost  for  each  designer.  (Fischer,  1989) 
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There  are  construction/tool  kits  available  for  the  design  of  human-computer 
interfaces.  The  interface  is  separate  from  the  application,  but  usually  this  is  an 
acceptable  approach.  Advantages  of  using  a  "toolkit"  include  the  availability  of  an 
environment  for  rapid  prototyping  of  a  class  of  interfaces,  a  high  quality  interface 
achieved  at  a  low  cost,  and  architectures  that  provide  uniformity  and  extensibility. 
(Fischer,  1989) 

In  the  design  of  the  interface,  the  designer  should  consider  the  use  of  prototypes. 
Since  a  detailed  specification  probably  does  not  exist,  and  the  interaction  between  the 
user  and  the  system  is  a  dynamic  relationship,  the  prototype  will  allow  the  user  a  chance 
to  "play"  with  the  prototype  interface.  The  user  then  provides  feedback  to  the  designer 
before  extensive  coding  of  the  actual  interface.  Concern  for  the  human  should  be  the 
driving  force  in  the  design  of  the  human-computer  interface.  The  interface  should  be 
comprehensible  to  the  user  and  use  a  natural  communication  process.  (Fischer,  1989) 

1.  EFFIGY 

EFFIGY  is  an  interactive  testing  and  debugging  system  designed  by  IBM. 
EFFIGY  is  a  symbolic  executer.  Instead  of  supplying  specific  constants  as  input  values, 
the  tester  supplies  symbols  and  runs  the  program  on  the  classes  of  input.  When  the 
control  flow  of  a  program  is  input  dependent,  EFFIGY  does  a  case  analysis,  producing 
output  formulae  for  each  class  of  inputs  determined  by  control  flow  dependencies. 
Appendix  A  is  an  EFFIGY  session  script  with  comments  in  italics.  (Ramamoorthy  and 
Ho,  1975) 
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EFFIGY  is  a  good  example  of  what  many  command-line  interfaces  looked  like  IS 
years  ago  and  still  look  like  today.  Limitations  of  the  system  hardware  and  operating 
system  had  some  effect  on  the  look  of  EFFIGY.  The  concerns  of  the  designers  at  IBM 
were  probably  more  on  what  EFFIGY  did  than  how  it  presented  its  findings.  The  system 
prompts  the  user  with  an  "  ► "  symbol.  All  the  lines  that  begin  with  this  symbol  in  the 
script  are  user  input.  Very  little  else  went  into  the  interface  design.  The  system  has  no 
menus  or  help  screens,  which  makes  for  a  very  steep  learning  curve  for  novice  users. 
Experienced  users  should  find  the  interface  adequate.  EFFIGY  allows  the  user  to  go 
through  the  program  and  choose  the  path  for  symbolic  testing.  It  provides  informative 
feedback  to  the  user  provided  the  system  receives  correct  input.  There  is  no  reversal  of 
actions  in  EFFIGY.  The  user,  once  he  masters  the  system,  could  find  the  output 
valuable.  EFFIGY  runs  on  CMS  under  VM/30  on  an  IBM  370  model  168.  The  CMS 
filing  system  and  context  editor  are  an  integral  part  of  EFFIGY  for  creating,  changing 
and  storing  procedures  and  command  files.  Considering  when  IBM  developed  the 
system,  it  produced  interesting  output  through  a  fair  interface. 

In  recent  years  the  UNIX  operating  system  has  been  the  development  emironment 
of  most  software  testing  tools,  probably  because  of  its  widespread  use  in  software 
development  in  colleges  and  universities.  It  is  flexible  and  potent  to  work  in,  but 
demanding  upon  the  novice  user.  Its  proliferation  made  it  necessary  for  inexperienced 
users  to  access  UNIX’s  rich  functionality.  The  predilection  toward  better  UNIX 
interfaces  is  catching  on  with  the  introduction  of  new,  more  advanced  hardware. 
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2.  ASSET 


ASSET  (A  System  to  Select  and  Evaluate  Tests)  is  an  interactive  software 
testing  tool  based  on  dataflow  testing.  (Frankl,  1987,  p.  1)  ASSET  is  still  a  "work  in 
progress”  designed  to  work  in  the  UNIX  environment.  ASSET  accepts  syntactically 
correct  programs  written  in  a  subset  of  Pascal.  Appendix  B  is  a  script  from  an  ASSET 
session.  ASSET  uses  the  command-line  format,  incorporating  help  messages,  menus  and 
consistent  prompts.  ASSET  offers  informative  feedback  to  users  when  they  make 
mistakes.  It  allows  users  to  correct  and  continue  processing,  providing  contained  choices 
where  necessary.  The  ASSET  "command  level  prompt"  is  distinct  from  sub-prompts  to 
help  the  user  identify  where  he  is  at  any  time.  The  type  of  data  that  ASSET  provides 
the  tester  is  useful  and  interesting.  It  automatically  instruments  the  program  before 
compilation,  and  helps  the  tester  by  tracking  which  paths  in  a  procedure  or  function  the 
tester  has  yet  to  exercise.  It  also  produces  a  graphical  representation  of  the  paths 
available  in  a  procedure  or  function.  This  graph  is  useful  when  analyzed  with  the  copy.p 
file.  ASSET  and  tools  like  it  have  potential  as  part  of  the  integrated  environment 
discussed  earlier.  Some  researchers  are  beginning  to  design  their  interfaces  so  other 
testing  tools  can  eventually  integrate  into  their  environments.  The  Mothra  testing  tool 
is  an  available  tool  with  this  vision. 

3.  Mothra 

Purdue  University’s  Mothra  is  an  integrated  set  of  tools  and  interfaces  that 
support  the  planning,  definition,  preparation,  execution,  analysis  and  evaluation  of  tests 
of  large  systems.  (Lutz,  1990)  Mothra  lets  you: 
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•  selectively  and  systematically  create  mutant  programs 

•  execute  the  mutants  on  test  data 

•  compare  the  resulting  mutant  output  with  that  of  the  original  program 

•  measure  test  data  adequacy 

The  basis  for  Mothra  is  mutation  analysis,  which  evaluates  the  adequacy  of  test 
data  used  while  testing  a  program.  It  does  this  by  introducing  syntatically  correct 
changes  into  a  program,  where  each  change  represents  a  likely  error  that  the  programmer 
might  make.  (Lutz,  1990)  Appendix  C  is  a  script  of  a  session  with  Mothra  run  on  the 
VAX  711/85.  A  windowed  interface  exists  for  Mothra  with  additional  graphics 
enhancements  still  under  development.  The  designers  of  Mothra  developed  a  much  more 
sophisticated  interface  than  the  previous  tools  mentioned.  Mothra  makes  extensive  use 
of  menus  and  sub-menus  throughout,  that  jog  the  user’s  memory.  It  is  a  sophisticated 
tool  that  requires  time  to  learn.  Like  ASSET,  there  are  consistent  sequences  of  actions 
and  similar  terminology  for  prompts,  menus  and  help  screen.  Appendix  C  shows 
feedback  from  Mothra.  The  system  is  constantly  reporting  back  to  the  user  what  is 
happening  during  each  phase  of  mutant  generation  and  testing,  providing  informative 
feedback  to  the  user.  Mothra  allows  the  user  to  return  to  previous  menus  so  actions  are 
reversible.  It  also  has  on-line  error  checking  and  help.  The  developers  organized 
Mothra’s  output  in  a  logical,  useful  manner  for  the  user.  They  used  tables  and 
histograms  whenever  possible  to  organize  and  display  data.  The  user  can  look  at 
whatever  data  he  likes  through  a  system  of  menus.  The  Mothra  project  is  an  ongoing 
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effort  that  will  eventually  incorporate  other  testing  techniques  into  the  interface  to  create 
the  type  of  testing  environment  described  earlier. 

The  environments  examined  here  need  to  mature  even  more  before  they  can 
resemble  the  integrated  testing  environment  needed  to  test  and  verify  the  large  software 
systems  of  the  future.  The  literature  suggests  that  Mothra  is  on  the  leading  edge  of 
automated  testing  technology  coupled  with  advanced  interface  design.  It  deserves  further 
study.  Researchers  should  develop  interface  designs  concurrently  with  the  testing  tools. 
They  must  consider  human  factors  in  their  designs.  Good  interface  designs  will  improve 
performance,  speed,  error  rates  and  user  satisfaction.  The  future  of  automated  testing 
will  have  to  make  use  of  new  technology  to  test  the  increasingly  complex  software 
systems  of  the  future. 

F.  PROBLEM  STATEMENT 

Graphical  user  interfaces  have  become  an  integral  aspect  of  software  design. 
Though  software  testing  tools  tend  to  be  used  by  a  select  group  of  skilled  software 
testers,  ease  of  use  is  a  factor,  and  a  good  interface  will  help  to  move  a  testing  tool  from 
simply  research  to  a  practical  level.  Our  goal  is  to  use  the  eight  principles  proposed  by 
Shneiderman,  combined  with  testing  tool  output  representation  to  design  an  interface  to 
assist  in  the  use  of  failure  region  analysis  tools.  In  doing  this,  we  will  identify  general 
principles  for  the  design  of  testing  tool  interfaces  and  indicate  issues  that  remain  to  be 
explored. 
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The  work  involved  in  the  completion  of  this  thesis  was  split  between  the  authors. 
LCDR  Abel  concentrated  on  the  user  interface  aspects  of  the  research  and  coding  of 
VIEWER,  while  CAPT  Monti  concentrated  on  the  tool  interface  aspects  of  the  research 
and  coding  of  VIEWER. 

G.  OVERVIEW  OF  REMAINING  CHAPTERS 

Chapter  n  examines  the  way  the  tool  interface  has  been  developed  and  how  it 
reflects  the  principles  of  "good"  interfaces.  A  brief  description  of  each  tool  is  provided, 
and  its  relation  to  the  interface  developed  as  well  as  the  representation  of  each  tools 
information. 

Chapter  III  provides  an  extended  walkthrough  and  information  necessary  for  the 
user  to  use  the  interface. 

Chapter  IV  provides  a  conclusion  and  a  summary  of  what  has  been  accomplished 
thus  far.  It  also  indicates  those  areas  that  require  more  research.  We  explore  the 
advantages  of  using  the  tools  via  the  VIEWER  graphic  interface  vice  command  line  or 
other  type  of  interface. 
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n.  TOOL  DESCRIPTION 


A.  TOOL  OVERVIEW 

The  process  of  analyzing  failure  regions  begins  with  a  compilable  Pascal  program 
with  one  or  more  known  faults.  A  set  of  five  tools  analyzes  the  failure  regions 
associated  with  the  identified  faults  in  the  program.  This  set  consists  of  REACHER, 
WALKER,  LISTER,  FALTER  and  SPACER.  (See  Figure  2.1.)  REACHER  and 
WALKER  derive  the  conditions  under  which  each  program  block  in  the  Pascal  program, 
procedure  or  function  may  execute.  The  REACHER  program  is  non-interactive  and  is 
the  first  step  in  the  analysis  of  failure  regions.  It  accepts  compilable  Pascal  source  code 
as  input.  REACHER  creates  an  "acfg",  an  annotated  control  flow  graph,  for  each 
module  of  the  Pascal  source  code.  REACHER  annotates  the  graph  with  the  conditions 
needed  to  reach  each  node  from  the  preceding  node.  The  output  from  REACHER  is  in 
a  format  usable  by  WALKER,  LISTER  and  FALTER.  WALKER  interactively  leads  the 
user  through  a  traversal  of  the  control  flow  graph(s)  associated  with  the  program.  The 
result  of  WALKER  is  an  acfg  annotated  with  the  conditions  under  which  the  tester 
reaches  each  node  from  the  start  of  execution.  (Shimeall,  REACHER,  p.  6) 

LISTER  outputs  an  annotated  source  listing  that  provides  a  correspondence  between 
statements  in  the  Pascal  source  code  and  the  control  flow  graph  nodes.  This  listing 
assists  the  analyst  in  the  use  of  WALKER  and  FALTER. 
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Figure  2.1  VIEWER  Context  Diagram 
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FALTER  records  the  conditions  under  which  calculations  in  the  defective  code 


produce  an  erroneous  result.  It  accepts  as  input  the  annotated  control  flow  graph  (acfg) 
from  REACHER  or  WALKER.  FALTER  also  records  the  effect  of  a  program  defect 
on  the  local  program  state.  The  result  is  a  faulted  control  flow  graph  that  serves  as  input 
to  SPACER.  (Shimeall,  FALTER,  p.  2) 

SPACER  interactively  analyzes  the  faulted  control  flow  graph,  calculating  the  final 
failure  bounds.  It  analyzes  those  conditions  where  later  processing  does  not  mask  the 
erroneous  value. 

B.  VIEWER  OVERVIEW 

Testing  tools  are  a  recent  development  in  the  area  of  software  engineering.  Their 
design  placed  little  or  no  emphasis  on  the  interface  provided  to  the  tester.  A  command 
line  interface  is  most  common.  A  screen-oriented  interface  can  free  the  tester  from 
certain  responsibilities  and  allow  them  to  focus  on  the  issue  at  hand,  i.e.,  the  testing 
process. 

VIEWER  is  an  interactive,  graphical  user  interface.  It  facilitates  the  process  of 
analyzing  a  program  to  determine  the  region  of  the  input  space  that  a  known  fault  maps 
onto  a  failure.  VIEWER  provides  a  screen-oriented  interface  to  the  analysis  tools.  A 
screen-oriented  interface  provides  many  capabilities.  It  can  reduce  the  amount  of 
information  shown  to  the  user,  so  it  allows  the  user  to  concentrate  on  the  important  facets 
of  the  information.  Multiple  views  of  the  same  information  may  be  provided  during 
program  analysis.  A  screen-oriented  interface  can  better  isolate  the  properties  of  the 
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information.  It  allows  the  carrying  across  of  information  between  tools  to  allow  better 
tracking  of  the  testing  process.  VIEWER  provides  automated  coordination  between  the 
tools,  freeing  the  analyst  from  dealing  with  automatable  detail.  This  coordination  is 
important  in  the  maintenance  of  a  certain  level  of  abstraction  for  the  user.  VIEWER 
provides  shorthand  options  for  common  commands  and  command  sequences.  This  allows 
for  rapid  and  customized  improvement  in  the  automation  of  the  analysis  process  as  more 
use  of  the  tools  suggests  new  automation  strategies.  (Shimeall,  VIEWER,  p.  2) 
VIEWER  uses  several  windows  to  interface  to  the  analysis  tools. 

C.  SUNVIEW  OVERVIEW 

SunView  is  the  Sun  Visual/Integrated  Environment  for  Workstations  (SunView  1 
Programmer’s  Guide,  p.  3).  It  is  a  user  interface  toolkit  that  provides  support  for  the 
creation  of  interactive,  graphics  based  applications  run  within  windows.  The  features  of 
SunView  aiding  the  design  of  user  interfaces  made  it  an  obvious  choice  for  the 
implementation  of  VIEWER. 

SunView  has  building  blocks  for  display,  and  a  run-time  system  for  input 
management.  The  building  blocks  are  visual  representations  of  objects  used  to  assemble 
the  user  interface.  (See  Figure  2.2,  from  Beer,  p.  49.) 

Included  in  the  building  blocks  are  two  basic  classes  of  windows:  frames  and 
subwindows.  The  purpose  of  a  frame  is  to  tie  subwindows  of  different  types  together 
so  they  can  serve  as  a  unit.  There  are  four  types  of  subwindows  provided  by  SunView: 
canvases,  text  subwindows,  panels  and  tty  subwindows.  A  canvas  is  a  subwindow  into 
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Figure  2.2  SunView  Building  Blocks 
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which  a  program  can  draw.  A  text  subwindow  displays  text  and  has  built-in  editing 
capabilities.  A  panel  subwindow  contains  items  such  as  buttons,  text  items,  menus, 
choice  items,  and  sliders.  A  tty  subwindow  is  a  terminal  emulator  in  which  the  user 
enters  commands  and  executes  programs.  (SunView  1  Programmer’s  Guide,  p.  3) 

SunView  applications  draw  graphics  through  Pixwin  constructs.  The  most  basic 
use  is  in  a  canvas  subwindow.  (SunView  1  Programmer’s  Guide,  p.  101)  SunView 
provides  some  built-in  pixwin  operations  (vector,  text,  polygon,  polypoint,  line,  etc.). 
Drawing  operations  should  not  spill  over  into  other  windows  and  they  should  not  be 
visible  in  portions  of  the  window  covered  by  other  windows.  The  pixwin  construct  and 
operations  provide  an  interface  that  meets  the  two  above  conditions.  (SunView 
Programmer’s  Manual,  p.  103)  Low-level  operations  on  SunView  images  support  and 
supplement  these  Pixwin  operations. 

A  SunView  image  on  the  screen  and  in  memory  is  composed  of  dots  called  pixels. 
SunView  represents  the  image  internally  as  a  rectangle  of  pixels.  The  pixrect  structure 
is  the  construct  used  at  a  low  level  to  access  an  image  and  operate  on  the  image. 
(SunView  1  Programmer’s  Guide,  p.  103)  This  access  and  operation  are  not  window- 
based,  so  the  user  must  avoid  overwriting  areas  of  the  screen. 

SunView  is  a  notification-based  system.  A  central  notifier  in  each  application 
distributes  input  to  the  appropriate  window.  The  notifier  is  a  mechanism  that  distributes 
events  within  a  process.  (SunView  1  Programmer’s  Guide,  p.  20)  SunView  provides 
predefined  notify  procedures  or  the  programmer  may  define  new  ones. 


30 


While  windows  are  the  most  important  class  of  SunView  objects,  they  are  not  the 
only  objects  available.  An  icon  is  a  small  image  that  represents  the  application. 
Command-related  features  include  scrollbars,  menus,  and  panel  items. 

SunView  allows  the  programmer  to  attach  scrollbars  to  canvases,  panels  and  text 
subwindows.  The  scrollbar  allows  the  user  to  determine  the  visible  area  when  the  object 
is  larger  than  the  window.  A  text  subwindow  has  a  vertical  scrollbar  by  default,  and 
cannot  contain  a  horizontal  scrollbar.  Panels  and  canvases  may  have  both  horizontal  and 
vertical  scrollbars.  It  is  the  programmer’s  responsibility  to  create  the  scrollbars  for  these 
subwindows.  (SunView  1  Programmer’s  Guide,  p.  267) 

A  menu  allows  the  user  to  make  choices  and  issue  commands.  They  differ  from 
windows  in  that  menus  are  visible  while  pressing  the  RIGHT  mouse  button.  Also,  menus 
are  less  flexible,  for  they  allow  the  user  to  choose  only  from  a  list  of  options. 

A  panel  item  is  a  panel  component  that  simplifies  a  particular  user-application 
interaction.  They  include:  message  items,  buttons,  and  text  items.  A  message  item  is 
only  visible  as  its  label.  They  display  text  to  the  user.  A  button  item  allows  the  user 
to  initiate  commands.  A  default  image  provided  by  SunView  represents  the  button,  or 
the  programmer  may  define  an  image  for  the  button. 

A  text  item  is  a  type-in  field.  The  notify  procedure  indicated  may  accept  input  by 
character,  on  specified  characters,  or  by  the  entire  field.  (SunView  1  Programmer’s 
Guide,  p.  159)  The  value  of  the  text  item  is  the  string  entered  by  the  user.  This  string 
appears  on  the  screen  after  the  label.  (SunView  1  Programmer’s  Guide,  p.  178)  Panel 
items  all  have  a  label  component.  The  label  is  a  string  or  graphical  image.  The  button, 
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choice,  toggle,  and  text  items  have  a  menu  component  that  allows  the  user  to  select  the 
item  directly  or  select  from  the  item’s  menu. 

Complex  and  flexible  objects  are  the  basis  of  the  SunView  model.  Since  SunView 
can  only  handle  very  simple  topologies  by  default,  there  are  attributes  to  allow  the  user 
to  specify  more  complex  layouts.  The  basic  idea  is  to  use  a  small  set  of  functions  with 
a  large  set  of  arguments  (attributes)  to  manipulate  the  objects.  SunView  functions  use 
variable  length  attribute  lists,  so  a  given  call  to  create  or  modify  an  object  mentions  only 
the  relevant  attributes.  Most  functions  in  SunView  take  pairs  of  attributes  and  values. 
The  number  of  pairs  varies  depending  on  how  many  attributes  the  programmer  wishes 
to  set.  (Beer,  p.  50) 

SunView  provides  a  high  level  of  abstraction  in  the  design  of  interfaces.  It  also 
provides  the  complexity  needed  to  design  an  interface  of  the  type  desired.  The 
subwindows  available  in  SunView  provide  precisely  the  functions  needed  to 
represent/display  the  results  and  output  from  the  analysis  tools. 

1.  VIEWER  Internal  Structure 

VIEWER  includes  interfaces  for  each  of  the  interaction  tools.  The  interfaces 
interact  with  one  another  and  with  the  testing  tools.  There  also  is  interaction  between 
the  subwindows  of  each  interface.  (See  Figure  2.3.)  The  VIEWWIN  interface  contains 
a  tty  subwindow  and  a  panel  subwindow.  The  tty  subwindow  receives  commands  from 
the  panel  subwindow,  or  accepts  command  line  input.  The  panel  subwindow  contains 
a  text  input  area  and  buttons  for  initiating  the  interfaces  for  WALKER  (WALKWIN), 
FALTER  (FALTWIN)  and  SPACER  (SPACEWIN). 
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Figure  2.3  VIEWER  Subblocks 
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The  WALKER  interface  is  WALKWIN.  It  allows  for  interactive  use  of  WALKER 


and  the  ability  to  call  the  non-interactive  REACHER  and  LISTER.  WALKWIN  is  a 
frame  with  four  subwindows  in  it.  The  text  subwindow  allows  the  user  to  view  Pascal 
source  code  or  other  text  files.  The  tty  subwindow  is  the  link  to  the  operating  system, 
and  displays  the  output  of  WALKER.  The  panel  subwindow  contains  buttons,  text  input 
area  and  a  menu,  and  all  interact  with  WALKER. 

The  canvas  subwindow  displays  the  control  flow  graph.  The  control  flow  graph 
is  an  integral  part  of  the  analysis  of  the  failure  region(s).  A  visual  representation  of  this 
graph  aids  the  user  in  the  test  process.  It  presents  information  so  the  user  can  track  the 
conditions  and  location  through  the  traversal  of  the  graph.  Though  not  present  in  the 
prototype  interface,  a  facility  for  interaction  directly  with  WALKER  via  the  control  flow 
graph  display  is  under  construction. 

The  text  subwindow  displays  text  files.  While  the  user  is  testing  a  particular  Pascal 
program,  he  displays  the  program  in  the  text  window.  He  also  can  load  other  files  into 
the  text  subwindow.  For  example,  during  the  running  of  WALKER,  the  user  may  want 
to  display  a  textual  representation  of  the  control  flow  graph.  He  may  want  to  review  the 
output  from  LISTER  or  other  information  about  the  faults  in  the  code.  The  scrollbar 
allows  the  user  to  move  quickly  to  the  top  or  bottom  of  the  file,  move  line  by  line,  or 
move  to  an  area  of  the  file. 

The  tty  subwindow  provides  an  area  to  record  WALKER  commands  and  displays. 
It  allows  the  expert  user  to  dispense  with  buttons  and  use  keyboard  entry.  The  tty 
subwindow  also  accepts  UNIX  commands,  i.e.,  listing  the  files  in  the  current  directory. 
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The  panel  subwindow  contains  the  panel  items  used  for  interaction  between  the  user 
and  WALKER.  The  buttons  are  single  action  items,  some  of  which  use  the  string  input 
provided  by  the  message  item.  The  menu  contains  other  functions,  in  the  order  in  which 
the  user  probably  will  need  them  -  run,  help,  save  and  quit.  Buttons  do  not  function 
unless  the  user  is  running  WALKER.  The  user  may  find  that  additional  common 
command  sequences  should  be  represented  as  buttons.  The  programmer  can  create  new 
buttons  and  add  them  to  the  panel  subwindow. 

The  FALTER  interface  is  FALTWIN.  It  is  similar  in  function  to  WALKWIN,  and 
therefore  similar  in  representation  and  composition.  It  also  has  a  base  frame  with  four 
subwindows  -  canvas,  text,  tty  and  panel.  The  menu  selections  are  the  same  as  for 
WALKWIN.  But  the  use  of  the  other  component  parts  differs  from  WALKWIN. 

During  the  interaction  with  FALTER,  the  user  may  need  to  view  different  text  files 
than  they  used  with  WALKER.  They  may  be  interested  in  displaying  fault  information 
or  results  of  debug  sessions  to  characterize  the  effect  of  the  fault.  FALTWIN  also 
provides  different  button  choices  from  WALKWIN.  These  buttons  relate  to  the 
interaction  necessary  to  use  FALTER.  See  Chapter  m  for  an  example  of  this  use. 

In  the  prototype  of  VIEWER,  the  interface  to  SPACER  is  minimal.  A  tty 
subwindow  provides  an  area  for  the  user  to  invoke  LISP,  and  then  SPACER.  A  panel 
subwindow  contains  buttons  for  use  with  SPACER. 

The  interface  to  SPACER  is  limited  by  the  current  level  of  knowledge  concerning 
the  use  of  SPACER.  This  portion  of  failure  region  analysis  is  the  newest  area  of 
research.  It  is  not  yet  clear  what  is  the  best  way  to  represent  the  output.  A  strict 
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geometrical  approach  may  not  be  suitable  or  effective.  Two  dimensional  representations 
of  a  multi-dimensional  region  are  inadequate  or  incomplete.  Currently,  textual  output 
is  a  form  of  output  that  can  be  understood  and  evaluated  by  the  tester.  As  more  usage 
of  the  tool  occurs,  and  testers  develop  a  better  idea  of  what  the  key  properties  are,  a  way 
to  represent  these  properties  also  will  develop. 

The  other  tools  (WALKER  and  FALTER)  are  similar  to  other  testing  tools 
(particularly  static  analysis  tools  that  look  for  unreachable  code).  The  understanding  of 
the  key  properties  in  their  output/results  are  clear,  and  therefore  can  be  represented. 
While  SPACER  is  still  in  its  early  stages,  a  less  rigid  prototype  will  allow  the  interface 
to  develop  with  the  tool. 

D.  WALKTHROUGH  OF  FUNCTIONS  OF  MAIN  PARTS 

This  section  contains  specific  explanations  for  the  algorithms  used  in  the 
development  of  the  interfaces.  A  copy  of  the  code  is  in  Appendix  E. 

1.  VIEW  WIN 

a.  Declarations 

The  VIEWWIN  code  begins  by  including  the  SunView  header  files 
necessary  for  using  the  desired  SunView  functions  and  procedures.  Following  these 
header  files  are  macros,  variable  declarations,  and  procedure  declarations.  To  use  an 
icon  when  closing  a  frame,  the  programmer  must  load  the  icon  image  into  an  array. 
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Using  the  mpr_static()1  macro,  the  programmer  puts  this  array  into  a  pixrect  structure 
for  use  with  the  icon_create()  function  within  the  main  block  of  the  program. 

b.  Frame  and  Subwindows 

VIEWWIN  contains  a  tty  subwindow  and  a  panel  subwindow.  (SunView 
1  Programmer’s  Guide,  p.  213)  Attributes  set  the  heights  and  widths.  Each  subwindow 
has  attributes  identifying  that  they  belong  to  the  base  frame,  and  what  type  of  subwindow 
they  are.  The  WIN  BELOW  attribute  places  the  panel  subwindow  below  the  tty 
sub  window. 

The  function  window Jtfbase Jrame)  adjusts  the  VIEWER  base  frames 
to  contain  the  various  subwindows.  This  is  useful  when  the  user  want  to  scale  the 
window  size  in  SunView.  The  function  window_create()  does  not  display  the  windows 
on  the  screen.  The  function  window  main  Joop (base Jrame)  displays  all  created  (and 
visible)  objects  on  the  screen  and  puts  the  tool  in  a  loop  awaiting  user  input.  The 
VIEWER  interface  objects  must  appear  before  the  call  to  window  main  loop ().  (Beer, 
P-  51) 

All  the  VIEWER  interfaces  use  the  window _create()  function  for  all 
types  of  windows.  This  function  returns  a  handle  to  the  object  created,  and  the  handle 
declaration  appears  at  the  top  of  the  program.  Changing  the  attributes  passed  to  the 
window  creaie ()  function  controls  the  appearance  of  the  VIEWER  interface  windows. 
These  attributes  include:  the  parent  item,  a  label,  an  icon  and  other  information. 

1  In  the  text  of  this  thesis,  italicized  text  refers  to  SunView 
functions  and  procedures. 
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The  base_frame  does  not  have  a  parent  item,  so  this  attribute  is  NULL. 
For  each  base  frame,  a  defined  position  ensures  the  presentation  of  the  frames  is  in  a 
useful  and  consistent  manner.  Defined  positions  means  the  starting  location  of  the  (0,0) 
coordinate  for  the  base  frame.  The  user  could  change  these  starting  coordinates  within 
the  program,  or  move  the  frames  via  SunView  mouse/menu  commands.  The  label 
identifies  the  displayed  interface  for  the  user.  The  icon  attribute  provides  the  user  the 
ability  to  close  the  frame  and  have  a  relevant  picture  appear.  All  the  VIEWER  interface 
base  frames  have  icons  for  closing  the  frame.  (See  Figure  2.4.)  Icon  designs  jog  the 
memory  of  the  user  when  they  suspend  an  operation. 

By  default,  a  tty  subwindow  forks  a  shell.  It  is  necessary  to  send  button, 
menu,  and  text  input  to  the  tty  subwindow.  The  function  ttyswJnputQ  sends  input  to  the 
tty  subwindow.  It  appends  the  character  sequence  in  a  buffer  onto  the  tty’s  input  queue. 
It  returns  the  number  of  characters  accepted.  The  program  treats  the  characters  as  if 
they  were  a  keyboard  entry.  This  function  provides  a  simple  way  for  the  user  to  send 
input  to  the  program  running  in  the  tty  subwindow.  (SunView  Programmer’s  Manual, 
p.  213) 

The  panel  subwindow  contains  a  filename  input  area  (a  text  item)  and  a 
button  area.  The  text  item  provides  a  way  for  us  to  input  text  to  the  panel  subwindow 
that  the  tty  subwindow  uses  for  processing.  VIEWWIN  uses  the  panel _create_item ( ) 
function  with  attributes  for  the  subwindow  in  which  to  place  the  item,  the  prompt  to 
display,  and  the  length  of  input  displayed.  The  subwindow  displays  50  characters  due 
to  window  size  constraints.  The  length  of  the  input  field  defaults  to  80  characters. 
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VIEWWIN  Icon 


WALKWIN  Icon 


Figure  2.4  Icons 
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The  buttons  in  VIEWWIN  have  similar  definitions.  Each  button 


definition  uses  the  SunView  function  panel_create_item().  Attributes  for  the  buttons 
include  information  for  which  subwindow  is  the  parent,  that  it  is  a  button,  the  process 
to  notify  when  the  user  selects  the  item,  and  the  image  to  present  within  the  panel.  The 
SunView  function  panel _button_image()  defines  how  the  button  looks  in  the  panel.  The 
image  has  attributes  for  the  parent  window,  the  name  to  put  in  the  button,  the  width  of 
the  button,  and  the  font  style  to  use.  The  panel _button_image()  function  allowed  us  to 
keep  the  look  and  feel  of  the  VIEWER  interface  buttons  consistent  across  the  interfaces. 
Instead  of  a  name  consisting  of  a  string,  the  image  may  be  an  icon.  (Our  buttons  that 
activate  menus  in  WALK  WIN  and  FALTWIN  use  this  feature.) 

c.  Procedures 

Notify  procedures  that  serve  as  values  for  PANEL  NOTIFY  PROC 
attributes  are  included  in  the  code.  The  procedure  "call_reacher"  uses  the  filename 
entered  in  the  panel  subwindow  and  sends  a  command  to  run  REACHER  on  that  file. 
The  procedure  stores  the  filename  and  the  command  in  a  character  buffer,  and  sends  it 
to  the  tty  subwindow  of  VIEWWIN  via  the  ttysw  inputf)  function. 

The  "call_reacher"  procedure  displays  WALKWIN  with  the  text  of  the 
file  shown  in  the  text  subwindow.  To  accomplish  this,  declarations  include  a  character 
buffer  of  length  81,  an  event  of  type  Event  (SunView),  and  a  result  of  type  integer.  In 
order  to  provide  some  error  handling,  the  procedure  looks  for  a  "p"  as  the  last  character 
of  the  filename  as  an  attempt  to  ensure  proper  filename  format,  i.e.,  a  Pascal  file.  The 
procedure  loads  the  filename  into  a  buffer  and  the  checks  the  last  character.  If  the  last 
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character  is  a  "p",  the  procedure  loads  a  call  to  REACHER  concatenated  with  the 
filename  into  the  buffer  and  sends  the  result  to  the  tty  subwindow.  The  algorithm  sends 
a  command  to  the  tty  subwindow  to  open  WALKWIN  with  the  filename  as  a  parameter. 

If  the  last  character  is  not  a  "p",  the  "msg"  procedure  accomplishes  the 
error  handling.  This  procedure  displays  a  pop-up  frame  to  alert  the  user  of  an  improper 
filename  format.  (See  Figure  2.5.)  It  has  two  parameters:  a  string  (the  message  to 
display)  and  an  integer  (indicating  whether  to  output  beeps). 

Within  the  "msg"  procedure  is  used  an  integer  "result",  and  event,  and 
a  character  string  composed  of  the  message  "Press/ "Continue/"  to  proceed."  Result 
equals  the  return  integer  from  the  alert _prompt()  procedure.  A  SunView  alert  is  a  frame 
that  contains  one  subwindow,  a  panel.  The  alert _prompt()  function  may  set  attributes 
for  the  display  of  the  text  message(s),  the  position  of  the  frame,  beeping  characteristics, 
and  buttons.  (SunView  1  Programmer’s  Guide,  p.  202)  It  takes  as  parameters  the  frame 
under  consideration,  the  address  of  the  event  (user  action)  and  the  strings  used  (the 
message  sent  in  and  the  one  hard  coded  within  the  function).  It  pops  up  on  the  screen 
to  notify  the  user  of  a  problem  or  other  things  requiring  attention.  The  alert  has  full 
screen  access  -  the  screen  freezes  until  the  user  gives  a  response.  (SunView  1 
Programmer’s  Guide,  p.  199) 

Alerts  have  better  user  interface  facilities  than  mem _prompt(),  which 
offers  a  simple  box  with  no  more  than  two  choices.  Alerts  have  an  arrow  to  get  the 
user’s  attention,  buttons,  fonts,  beeps  and  a  3-D  shadow,  and  there  can  be  more  than  two 
choices.  (SunView  1  Programmer’s  Guide,  p.  199) 
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The  alert _prompt()  function  creates  the  alert,  pops  it  on  the  screen, 
handles  the  user  interaction,  removes  the  alert,  and  returns  a  value.  The  alert  used  by 
VIEWWIN  has  only  one  button  -  "continue"  -  since  it  only  serves  to  notify  the  user  of 
an  error  in  the  format  of  the  filename.  (Sun View  1  Programmer’s  Guide,  p.  202)  This 
is  the  only  choice  needed  by  the  user,  for  this  is  a  simple  alert  that  the  filename  is  in  an 
improper  format.  Pressing  the  continue  button  clears  the  pop  up  frame  from  the  screen. 
It  also  clears  the  filename  item  by  a  call  to  panel_set_value()  with  parameters  for  the 
panel  item  to  set  and  what  to  set  it  to  (an  empty  string). 

The  number  of  beeps  sounded  when  the  alert  appears  is  the  number  set 
by  the  user  in  their  defaultsedit  file.  The  programmer  can  set  the  alert  to  no  beeps 
despite  the  default.  Programmers  usually  reserve  beeping  for  unexpected  events.  A 
response  to  a  request  would  normally  not  beep  when  displayed.  (SunView  1 
Programmer’s  Guide,  p.  208) 

The  "call_falter"  procedure  uses  the  same  algorithm,  except  that 
VIEWWIN  does  not  call  FALTER  directly  from  the  button  invocation.  Since  FALTER 
is  interactive,  the  procedure  displays  the  interface,  passing  the  filename  as  a  parameter, 
and  the  user  runs  FALTER  from  FALTWIN.  In  a  progression  through  the  tools,  the 
filename  would  be  the  same  one  as  used  in  WALKWIN,  so  the  procedure  performs  no 
error  handling  here. 
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2.  WALKWIN  algorithms 


a .  Declarations 

WALKWIN  uses  several  header  files  not  found  in  the  VIEWWIN  source 
code.  This  interface  has  more  subwindows,  and  involves  graphics.  WALKWIN  includes 
two  icon  declarations.  One  represents  the  frame  and  the  other  is  an  image  for  a  button 
with  an  associated  menu.  This  allowed  us  to  differentiate  between  a  command  button, 
which  uses  the  default  SunView  image,  and  a  menu  button,  which  uses  the  imported 
image.  The  user  will  find  this  less  confusing. 

b.  Frame  and  Subwindows 

The  VIEWWIN  frame  passes  the  filename  to  WALKWIN,  which  assigns 
it  to  a  variable.  WALKWIN  uses  that  variable  to  load  the  file  into  the  text  subwindow 
using  the  SunView  window_set()  function.  The  WTN_X  and  WIN  Y  attributes  align  the 
WALKWIN  base  frame  with  the  VIEWWIN  frame. 

The  layout  of  WALKWIN’s  base  frame  and  subwindows  considers 
several  ergonomic  factors.  The  size  of  each  subwindow  is  large  enough  to  be  useful,  yet 
small  enough  to  create  an  organized  interface.  The  text  subwindow  displays  the  text  of 
the  Pascal  code  being  tested  next  to  the  representation  of  the  acfg  in  the  canvas 
subwindow.  WALKWIN  sets  its  subwindows’  height  and  width  attributes  in  pixels. 
This  allows  very  precise  arrangement  and  alignment  within  the  frame.  These  dimensions 
are  adjusted  to  allow  for  varying  resolution  in  display  screens. 
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WALKWIN’s  canvas  subwindow  has  attributes  for  height  and  width  of 
the  window  and  height  and  width  of  the  canvas.  The  canvas  is  larger  than  the  actual 
subwindow,  to  accommodate  large,  complex  graphical  structures.  Since  the  canvas  is 
larger  than  the  window,  WALKWIN  includes  scrollbars  for  moving  around  the  canvas. 
For  consistency  between  machines,  WALKWIN  defines  the  location  of  each  scrollbar 
explicitly,  since  different  users  may  have  different  values  in  defaultsedit.  WALKWIN 
uses  the  attributes  CANVAS_AUTO_EXPAND  and  CANVAS_AUTO_SHRINK  to  adjust 
automatically  the  canvas  size  when  scaling  the  window.  (SunView  1  Programmer’s 
Guide,  p.  69) 

The  attributes  of  the  text  subwindow  and  the  tty  subwindow  include 
placement  of  them  in  relation  to  the  canvas  subwindow,  using  WIN  RIGHT  OF  and 
WIN  BELOW.  WALKWIN’s  text  subwindow  has  an  attribute  to  set  the  word  wrap  at 
the  word  vhe  character  level.  This  makes  text  displayed  in  the  text  subwindow  much 
easier  to  read. 

Each  command  recognized  by  WALKER  has  a  corresponding  button 
within  the  panel  subwindow.  The  panel  also  has  a  menu  for  interaction  with  WALKER. 
The  menu  becomes  visible  when  the  user  presses  the  right  mouse  button  with  the  pointer 
on  the  menu  button.  We  used  the  PANEL_CHOICE  attribute  to  attach  the  menu  to  this 
button.  The  image  is  the  address  of  the  pixrect  of  the  icon  image,  as  discussed  earlier. 

The  panel  subwindow  has  three  text  items  for  entry  of  strings  to  use  with 
WALKER  commands  and  with  the  call  to  LISTER.  The  WALKER  input  area  provides 
string  input  for  all  the  WALKER  commands.  LISTER  format  requires  an  input  filename 

■5 


and  a  name  for  the  output  file  it  creates.  We  explicitly  positioned  the  text  items  within 
the  panel  subwindow.  The  WALKER  input  displays  up  to  50  of  the  80  allowable  input 
characters,  to  allow  for  the  input  of  the  conditions  or  annotations.  Since  LISTER  inputs 
consist  of  only  filenames,  these  text  items  display  15  of  the  allowable  80  character  input. 

c.  Algorithms 

(1)  Circles  and  lines 

We  conceived  a  graphical  representation  of  the  acfg  as  circles  to 
represent  the  nodes  and  lines  to  represent  the  connections  between  the  nodes.  The 
Sun  View  pw_vector()  provides  a  simple  mechanism  for  drawing  lines  in  the  canvas 
subwindow.  Drawing  a  circle  in  SunView  is  not  as  simple.  There  is  no  predefined 
pixwin  or  pixrect  function  for  a  circle. 

SunView  allows  the  programmer  to  import  an  icon  image  into  a 
pixwin  object  and  display  it  within  the  canvas  subwindow.  The  problem  was  that  the 
shape  of  the  image  is  a  square.  There  was  some  difficulty  involved  in  removing  the 
comers  so  the  circle  remained. 

A  polygon,  with  the  number  of  sides  set  high  enough,  approximates 
a  circle.  To  draw  polygons,  WALKWIN  uses  the  pw _polygon_2( ')  function.  Initially, 
we  used  the  operation  PIX_SRC  to  fill  the  polygon  reverse  of  the  background.  Briefly, 
PIX_SRC  sets  all  pixels  to  true,  so  the  polygon  appeared  in  reverse  video  on  the  white 
canvas  background. 
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Aesthetically,  we  felt  the  circles  representing  nodes  should  be 
unfilled  -  that  is  the  center  should  be  the  same  as  the  background.  We  tried  the  operation 
PIX_CLR,  which  displays  the  polygon  in  the  same  color  as  the  background.  This  made 
our  polygons  invisible,  since  the  polygons  lacked  visible  outlines.  The  solution  was  to 
display  a  polygon  with  the  operation  of  PIX_CLR,  then  place  vectors  around  the  edge 
to  provide  the  outline  of  the  circle.  The  result  was  exactly  as  desired.  By  choosing  a 
very  large  number  for  the  sides,  we  achieved  a  smooth  "circle".  The  large  number  of 
sides  does  not  impact  adversely  on  the  speed  of  the  display  in  this  implementation. 

(2)  Graphical  Representation  ofACFG 

After  parsing  the  target  Pascal  source  file,  REACHER  produces  a 
control  flow  graph  of  the  source  code  in  textual  form  and  saves  this  graph  in  a  file  called 
"reacherout".  WALKER  reads  the  control  flow  graph  in  to  memory  so  the  user  can 
step  through  the  graph.  VIEWER  takes  the  control  flow  graph  provided  by  REACHER 
and  produces  a  graphical  representation  of  reacher  out  in  the  canvas  subwindow  of 
WALKWIN.  To  accomplish  this  we  used  the  same  macros,  definitions  and  structures 
used  by  WALKER  to  dynamically  allocate  memory  and  load  "reacher_out"  into  memory. 
With  the  help  of  our  previous  experience  in  constructing  Sun  View  lines  and  polygons, 
we  designed  an  algorithm  to  read  the  control  flow  graph  and  produce  the  graphical 
representation  of  it.  The  next  section  briefly  describes  this  algorithm. 

After  WALKWIN  reads  the  control  flow  graph  into  memory,  it  sets 
a  pointer  called  cumode  to  the  root  node  in  the  control  flow  graph.  We  use  a  do-while 
loop  to  read  the  binary  tree  and  draw  the  graph.  The  do-while  loop  processes  the  graph 


47 


as  long  as  the  following  conditions  exist:  the  current  node’s  left  child  is  not  equal  to 
null,  or  the  current  node’s  right  child  is  not  equal  to  null,  or  the  top  of  the  stack  is 
greater  than  zero.  When  these  conditions  exist  then  processing  inside  the  loop  uses  three 
conditionals  to  draw  the  graph  in  the  walkwin  canvas.  The  algorithm  first  checks  to  see 
if  the  current  node  has  a  right  child.  If  it  does,  walkwin  pushes  the  node  onto  an  acfg 
stack,  and  increments  the  stack  pointer.  We  assume  that  since  the  node  has  a  right  child 
it  also  must  have  a  left  child.  The  algorithm  computes  the  (x,y)  coordinates  for  the  next 
left  node  and  draws  a  line  from  the  current  (x,y)  location  to  the  left  node  (x,y)  location 
using  the  SunView  pw_vector()  function.  We  then  draw  a  circle  at  the  current  (x,y) 
location  using  techniques  discussed  earlier.  We  save  the  current  (x,y)  coordinates  in  a 
position  array  and  move  our  current  (x,y)  position  to  the  location  of  the  left  child.  The 
program  marks  the  current  node  and  the  cumode  pointer  moves  to  the  left  child. 

If  the  right  node  is  null  the  algorithm  checks  to  see  if  the  left  node 
is  null.  If  it  is,  we  decrement  the  acfg  stack  pointer  and  the  node  on  the  top  of  the  stack 
becomes  the  current  node.  The  algorithm  computes  the  (x,y)  coordinates  of  the  right 
node  and  stores  the  position  of  the  current  node  in  the  position  array.  We  call 
pw_vector()  to  draw  a  line  from  the  current  (x,y)  location  to  the  right  node  (x,y) 
location.  We  draw  a  circle  at  the  current  (x,y)  location,  then  move  the  current  (x,y) 
location  to  the  position  of  the  right  node.  The  current  node  becomes  the  right  child. 

If  the  current  node  has  no  right  child  and  the  left  node  is  not  null 
then  the  current  node’s  left  child  becomes  the  current  node.  The  algorithm  computes  the 
(x,y)  coordinates  for  the  next  left  node.  We  store  the  previous  cumode  (x,y)  location 
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in  the  position  array  and  use  pw_vector()  to  draw  a  line  from  the  current  (x,y)  location 
to  the  new  cumode  (x,y)  location.  We  draw  a  circle  at  the  current  (x,y)  coordinates  and 
move  the  current  (x,y)  coordinates  to  the  position  of  the  cumode. 

During  this  looping  process  if  the  algorithm  moves  to  a  marked 
cumode,  then  we  call  a  while  loop  to  check  the  stack.  If  the  top  of  the  stack  is  greater 
that  zero  then  this  is  the  signal  to  pop  the  stack.  We  retrieve  the  position  of  the  marked 
cumode  from  the  position  array  and  this  becomes  our  current  (x,y)  coordinate.  The 
algorithm  computes  the  next  right  node  location  and  uses  pw_vector( ')  to  draw  a  line  from 
the  cumode  (x,y)  coordinates  to  the  coordinates  of  the  right  child.  We  move  the  current 
(x,y)  location  to  the  position  of  the  right  child  and  the  cumode  becomes  the  right  child. 
Then  we  pop  the  stack.  This  process  continues  in  a  while  loop  until  we  reach  an 
unmarked  node  or  TOS  is  equal  to  zero. 

(3)  Buttons  and  Menu 

Each  button  is  a  corresponding  notify  procedure.  They  use  a 
buffer  to  load  an  input  string.  The  string  includes  the  cryptic  command  for  WALKER 
and  the  additional  string  input  if  needed  by  that  particular  command.  The  annotate, 
change  condition,  join  and  goto  commands  use  the  additional  string  input  from  the 
WALKER  text  item. 

The  "Walker  Menu"  button  has  its  own  procedure  to  handle  input 
from  the  menu.  It  uses  the  event  received  from  the  mouse  action.  SunView  assigns  a 
value  to  each  choice  in  the  menu,  beginning  with  zero  for  the  first  item.  A  switch 
statement  delineates  the  action  to  take  based  on  the  value  detected.  The  variable 
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walker_run  indicates  whether  the  user  is  running  WALKER.  It  is  initialized  to  zero  in 
the  declarations  section  of  the  program.  When  the  user  selects  "Run"  from  the  menu, 
the  program  loads  the  command  to  run  WALKER  on  reacher_out  in  the  string  buffer. 
If  walker  run  equals  zero,  the  program  sends  the  string  to  the  tty  subwindow  and  sets 
walker_run  to  one.  The  panel_set_yalue()  function  resets  the  walker  input  area  to  an 
empty  string. 

The  other  menu  selections  check  for  walker  run  equal  to  one  before 
sending  the  string  to  the  tty  subwindow.  Each  contains  the  panel  set  value ( )  function 
to  reset  the  input  area.  In  addition,  the  "Quit"  selection  clears  the  tty  subwindow. 

The  "call  lister"  procedure  is  the  notifier  for  the  LISTER  button 
initiation.  It  composes  a  string  to  send  to  the  tty  subwindow  including  the  strings  for 
input  and  output  filenames  and  stores  it  in  a  buffer.  The  tty_input()  function  sends  the 
buffer  contents  to  the  tty  subwindow,  and  panel _set_value()  resets  both  the  input  string 
input  areas. 

E.  CONCLUSION 

This  chapter  provides  a  detailed  look  at  the  development  and  design  of  the 
interface.  Every  decision  in  the  design  considered  the  general  principles  outlined  in 
Chapter  I.  To  review  those  principles,  they  are: 

•  Consistency 

•  Frequent  Users  have  shortcuts 

•  Informative  Feedback 
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•  Dialogue  yield  closure 

•  Simple  error  handling 

•  Easy  reversal  of  actions 

•  Internal  Locus  of  control 

•  Reduce  short  term  memory  load 

Consistency  is  perhaps  the  most  crucial  of  these  principles.  The  size  and 
appearance  of  WALKWIN’s  buttons  reflect  this  consistency.  The  user  will  find  that  all 
functionally  similar  buttons  look  the  same.  WALKWIN  displays  buttons  that  represent 
a  menu  by  an  icon  so  the  difference  is  readily  apparent  to  the  user.  Though  each  tool 
has  a  different  way,  or  ways,  to  exit  the  program,  the  interfaces  to  the  tools  only  use 
"Quit"  in  the  menu. 

The  tty  subwindow  in  each  interface  provides  the  mechanism  for  expert  users  to 
use  shortcuts.  They  have  command  line  access  in  any  level. 

User  feedback  is  present  in  many  forms.  The  buttons  reverse  video  when  pressed, 
and  are  grey  until  action  completes.  This  also  provides  closure  dialogue.  Of  course,  this 
usually  occurs  so  quickly  the  user  sees  a  flash  of  reverse  color.  Titles  on  each  frame  are 
a  form  of  feedback.  It  is  a  way  to  verify  that  the  proper  interface  has  displayed.  The 
bubbles  in  the  scrollbars  move  at  the  command  of  the  user.  They  show  position  of  the 
user  in  the  canvas  or  in  the  text  subwindow. 

The  principle  of  user  feedback  also  appears  in  the  representation  of  the  information. 
The  user  can  see  analysis  results  in  several  forms  within  the  same  interface.  The  text 
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subwindow  presents  the  textual  form  of  the  Pascal  source  code,  while  the  canvas 
subwindow  presents  the  graphical  representation  of  the  acfg  corresponding  to  the  Pascal 
code.  They  can  see  the  information  change  as  the  analysis  proceeds. 

The  interface  provides  closure  when  the  user  selects  quit  from  the  menu  of 
WALKER  or  FALTER.  The  program  not  only  ends  the  execution  of  the  testing  tool, 
but  also  sends  a  command  to  the  tty  subwindow  to  clear,  signally  a  completion  of  the 
action. 

There  is  little  error  handling  in  VIEWER.  One  example  is  the  alert  pop  up  frame 
when  entering  the  filename  to  use  with  REACHER  and  FALTER.  When  the  filename 
does  not  end  in  "p",  the  alert  appears.  This  is  also  a  form  of  user  feedback. 

This  prototype  provides  reversal  of  action  in  the  use  of  icons.  Clicking  the  left 
mouse  button  on  an  icon  restores  the  operation. 

The  interface  provides  an  internal  locus  of  control.  The  user  is  in  control  of  the 
interaction  with  WALKER  and  FALTER. 

To  ease  the  load  on  short  term  memory,  the  buttons’  labels  use  a  descriptive  name 
vice  the  single  letter  command  recognized  by  the  program  to  which  it  interfaces.  Since 
all  buttons  are  available  for  the  user  to  see,  they  do  not  have  to  remember  the  cryptic 
commands. 

What  does  a  testing  tool  interface  need  to  represent?  The  analysis  of  failure 
regions  has  a  control  flow  graph,  so  an  ability  to  present  the  graph  is  important.  These 
tools  process  and  analyze  Pascal  source  code.  The  user  would  want  a  way  to  display  and 
review  the  text  and  examine  the  acfg  graph  while  they  are  running  the  tool.  The  tty 
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sub  window  supports  the  need  to  interact  with  a  running  program.  The  buttons  and  input 
areas  in  the  panel  are  for  easy  access  to  commands  and  other  reasons  delineated  above. 

VIEWER  allows  the  user  to  display  multiple  views  of  the  information  involved  in 
the  program  analysis.  They  can  isolate  the  pertinent  properties  and  concentrate  on  the 
process  of  testing.  The  interfaces  carry  across  information  between  the  tools.  The  tester 
tracks  the  processes  better  since  the  interface  reduces  the  amount  of  information  they 
need  to  assimilate. 
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m.  EXAMPLE  VIEWER  SESSION 


A.  ASSUMPTIONS 

The  discussion  in  this  chapter  uses  an  example  Pascal  program,  called  "getangle.p", 
which  has  a  known  fault.  In  this  program,  there  is  an  observer,  located  at  (XO,  YO), 
and  an  observed  object,  located  at  (XT,  YT),  with  width  W  and  length  L.  The  purpose 
is  to  compute  the  angle  occupied  by  the  observed  object  when  seen  from  the  observer’s 
location.  Appendix  E  contains  a  copy  of  the  code,  with  comments  showing  the  acfg  node 
numbers. 

We  assume  the  user  has  some  knowledge  of  Sun  Workstations  and  SunView.  Also, 
the  user  should  understand  failure  region  analysis  and  the  purpose  of  each  tool  involved 
in  the  process. 

B.  EXAMPLE 

1.  Initiate  SunView 

The  user  begins  by  initiating  SunView.  He  must  be  in  the  directory 
containing  the  Pascal  code  to  process.  The  user’s  command  path  must  contain  directories 
for  the  tools. 
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2.  VIEWER 


«.  Initiating  VIEWWIN 

To  start  VIEWER,  the  user  raters  "VIEWWIN"  at  the  prompt  within  a 
shell  window  of  SunView.  VIEWWIN  appears  on  the  screen.  The  upper  subwindow 
contains  a  UNIX  command  shell  prompt.  The  lower  subwindow  contains  a  text  entry 
area  with  the  label  "Filename:"  and  three  buttons,  one  each  for  WALKER,  FALTER, 
and  SPACER.  The  maximum  number  of  characters  the  user  can  enter  in  the  text  item 
is  80.  The  control  panel  only  displays  50  characters,  but  the  string  remains  valid  up  to 
80  characters.  The  user  will  lose  any  character  entered  beyond  the  limit  of  80. 
(SunView  1  Programmer’s  Guide,  p.  179) 

The  input  file  should  be  compilable  Pascal  source  code.  To  enter  the 
filename  for  processing,  the  user  moves  the  cursor  so  it  is  within  the  lower  subwindow. 
The  caret  at  the  text  entry  item  will  be  a  dark  triangle,  indicating  the  location  for  text 
input.  The  interface  will  not  allow  WALKER  to  run,  nor  display  WALKWIN,  unless 
the  filename  provided  ends  in  "p".  If  the  filename  does  not  have  the  proper  format, 
VIEWER  displays  a  pop-up  frame  indicating  that  the  filename  is  incorrect,  with  a 
continue  button.  Depending  on  the  default  setting,  a  beep,  or  a  series  of  beeps,  alerts 
the  user  of  an  error.  The  alert  automatically  places  the  pointer  on  the  "continue"  button. 
When  the  user  clicks  on  "continue"  using  the  left  mouse  button,  the  erroneous  filename 
disappears,  and  the  text  item  is  ready  for  a  new  entry.  The  pop-up  frame  is  a  blocking 
frame  and  recognizes  no  entries  until  the  user  presses  the  "continue"  button. 
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b.  Selecting  Analysis  Tools 

The  user  enters  "getangle.p"  at  the  input  text  item,  moves  the  pointer  to 
the  WALKER  button,  and  depresses  the  left  mouse  button.  (See  Figure  3.1.)  When 
pressing  a  button  item,  the  rectangle  inverts.  Upon  releasing  the  left  mouse  button, 
SunView  paints  the  rectangle  with  a  grey  background,  which  provides  feedback  that  the 
user  selected  the  item  and  executed  the  command.  The  grey  background  clears  when  the 
program  returns  from  the  notify  procedure.  (SunView  1  Programmer’s  Guide,  p.  167) 

REACHER  processes  the  Pascal  file,  and  output  appears  in  the 
VIEWWIN  tty  subwindow.  If  REACHER  is  successful,  the  message  "Successful  parse!" 
appears  in  the  tty  subwindow. 

3.  WALKWIN 

a.  Initiating  WALKWIN 

WALKWIN  positions  its  base  frame  on  the  screen,  relative  to 
VIEWWIN.  (See  Figure  3.2.)  The  label  at  the  top  of  the  window  identifies  the 
WALKWIN  interface.  WALKWIN  displays  the  code  for  "getangle.p"  in  the  text 
subwindow.  The  canvas  subwindow  displays  the  graphical  representation  of  the 
annotated  control  flow  graph  for  the  main  module  of  "getangle.p".  WALKWIN  provides 
scrollbars  for  the  text  and  canvas  subwindows.  The  canvas  subwindow  has  two 
scrollbars  -  horizontal  and  vertical  -  while  the  text  subwindow  has  only  a  vertical 
scrollbar.  Note  that  the  scrollbars  for  the  canvas  do  not  have  buttons  on  either  end, 
while  the  text  subwindow  scrollbar  has  buttons.  To  scroll,  the  user  moves  the  cursor 
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Vu-wrt  1.0 


Figure  3.1  VIEWWIN  Screen 
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Figure  3.2  WALKWIN  Frame 
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into  the  scrollbar  (the  bar  itself  or  the  buttons)  and  clicks  a  mouse  button.  (See  Figure 
3.3  for  the  possible  combinations.)  (SunView  1  Programmer’s  Guide,  p.271) 
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Figure  3.3  Text  Scrollbar  Mouse  Commands 


When  the  user  presses  a  mouse  button  inside  the  scrollbar,  the  cursor 
changes  to  preview  the  action  for  that  button.  Releasing  the  button  causes  the  action  to 
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execute.  Holding  the  mouse  button  down  repeats  the  action.  (SunView  1  Programmer’s 
Guide,  p.  271)  The  scrollbars  allow  the  user  to  see  parts  of  the  window  not  displayed. 

SunView  provides  standard  text  menus  for  the  code  displayed  in  the  text 
subwindow.  To  initiate  these  menus,  the  user  moves  the  cursor  to  the  text  subwindow, 
and  depresses  the  right  mouse  button.  SunView  provides  these  menus  for  the 
convenience  of  the  user.  They  are  not  a  necessary  part  of  the  failure  region  analysis 
tools.  The  user  can  find  a  detailed  explanation  of  these  menus  in  the  SunView  manual. 
The  tty  subwindow  also  has  a  built-in  menu.  The  canvas  and  panel  subwindows  do  not 
have  these  standard  menus. 

b.  Starting  WALKER 

The  panel  subwindow  runs  across  the  bottom  of  the  WALKWIN  frame. 
It  contains  all  those  items  necessary  for  the  interaction  with  WALKER,  and  the  running 
of  LISTER.  The  first  step  in  using  WALKER  is  to  run  the  program  from  the  Walker 
menu.  The  user  moves  the  pointer  to  the  WALKER  menu  icon,  and  presses  and  holds 
the  right  mouse  button.  A  menu  appears  with  four  choices  -  "Run",  "Help",  "Save"  and 
"Quit".  (See  Figure  3.4.)  Only  the  "Run"  option  will  function  at  this  point.  All  other 
menu  choices  and  the  buttons  on  the  top  row  do  not  function  unless  the  user  is  in  the 
interactive  mode  with  WALKER.  To  initiate  WALKER,  the  user  selects  "Run"  by 
moving  the  mouse  until  it  highlights  the  "Run"  command  and  releasing  the  mouse  button. 
This  action  calls  WALKER  on  the  default  file  name  produced  by  REACHER 
("reacher_out").  A  copy  of  "reacher_out"  appears  in  Appendix  F.  The  user  is  now  in 
the  interactive  mode  with  WALKER  and  output  appears  in  the  tty  subwindow.  For  a  list 
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'const  PI  .  3.1415926536; 
var  ang,XO,YO,XT,YT,V,Ltreal; 


function 

BAngle(XO,YO,XT,YT,fT,LTtreal)  treal; 
var  SA,SB,SC,SD,AX,AY,  BX,BY,  CX,CY, 
DX.DYi  real) 

Halffldth,  Half Length:  real) 


Ireal 


function  Slope  (Xl,Yl,X2,Y2:real) : 


begin 

Slope  i-  (Y2  -  Yl)  /  (X2  -  XI); 
end; 
begin 

Halffldth  i-  WT  /  2; 


tear 


U 


f  Annotate  )  fCondlUon)  f~Jofn~H  [~Coto  )  ("Prior"]  fUTT)  f  HlghV  1  f~T153^1  |~^Ty^ 

input  string: 

|  Uotor  input:  Lijtor  output: 


Figure  3.4  WALK  WIN  Menu 


of  possible  commands,  the  user  selects  the  "Help"  choice  from  the  WALKER  menu. 
WALKER  displays  help  information  in  the  tty  subwindow. 

c.  Traversing  the  graph 

The  user  runs  WALKER  to  achieve  a  couple  of  different  functions. 
After  REACHER  sets  up  each  link  of  the  graph  with  the  immediate  reachability 
conditions,  WALKER  goes  through  the  control  flow  graph  and  adds  up  those  conditions. 
On  the  other  hand,  the  user  wants  to  get  rid  of  pseudonodes.  These  are  nodes  that 
REACHER  generates  but  the  rest  of  the  analysis  doesn’t  require.  The  user  should 
collapse  these  nodes,  e.g.,  begin-end  nodes.  The  user  checks  the  code  displayed  in  the 
text  subwindow  to  be  sure  he  is  in  the  right  place.  The  canvas  subwindow  gives  the  user 
an  overview  of  the  control  structures;  the  text  subwindow  gives  the  user  program  details. 
The  user  selects  buttons  in  the  panel  subwindow  by  positioning  the  pointer  on  the  button 
and  depressing  the  left  mouse  button. 

The  user  starts  at  the  begin  node  of  the  main  program.  This  is  node  71, 
located  on  line  70.  The  "@"  prompt  shows  the  line  number  in  parentheses  and  the  text 
of  the  line.  A  begin-end  statement  is  indicated  by  a  blank  line.  The  "c"  prompt  shows 
the  current  reachability  condition.  It  is  always  "true"  for  the  first  node.  The  program 
gives  the  condition  it  is  about  to  set,  not  the  condition  used  to  reach  this  node.  The 
program  sets  the  conditions  on  the  exit  of  the  node.  The  left  arc  gives  the  condition  and 
the  right  arc  gives  the  not  of  the  condition.  The  "a"  prompt  shows  commentary  made 
by  the  analyst.  This  field  allows  the  analyst  to  make  comments  that  will  help  him  later 
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in  the  analysis  process,  but  the  comments  are  not  processed  by  any  tool.  The  user 
displays  line  71  in  the  text  subwindow  by  scrolling  down  the  text. 

The  user  knows  he  wants  to  traverse  the  nodes  of  all  modules  in  the  acfg. 
Looking  at  the  acfg  representation  in  the  canvas  subwindow,  the  user  sees  the  traversal 
in  the  main  module  of  getangle.p  consists  of  a  series  of  left  branches.  The  user  goes  left 
from  node  71  by  clicking  on  the  "Left"  button  in  the  panel  subwindow.  The  program 
sends  the  proper  command  to  the  tty  subwindow  telling  WALKER  to  go  left.  The  user 
is  now  at  the  node  72,  which  is  the  "readln"  statement  of  the  main  module.  It  is  a  good 
idea  to  join  these  two  nodes,  since  node  71  is  a  pseudonode  for  the  begin-end  statement 
and  unnecessary  in  later  processing.  The  user  enters  the  string  "71  72"  in  the  "Walker 
input"  area.  He  then  moves  the  pointer  to  the  "Join"  button,  and  clicks  on  this  button 
to  join  nodes  71  and  72.  The  result  is  node  72,  with  a  different  line  number  and  an 
updated  text  string.  (See  Figure  3.5.) 

The  condition  is  still  true.  The  user  goes  left  to  node  73,  which  is  a  call 
to  the  function  Angle.  Node  74  is  the  assignment  of  the  result  of  that  call  to  the  variable 
"ang".  This  is  another  pseudonode  generated  by  REACHER.  The  other  tools  do  not  use 
pseudonodes  so  the  user  can  join  nodes  73  and  74.  WALKER  knows  the  text  of  one  is 
a  substring  of  the  text  if  the  other  so  it  doesn’t  duplicate  the  text  string.  The  line  number 
is  still  72.  (See  Figure  3.6.)  The  user  goes  left  to  node  75,  which  is  the  "writeln" 
statement  of  the  main  module.  This  is  the  last  node  in  the  main  module.  The  user 
simplified  the  main  module  of  getangle.p  by  joining  pseudonodes  to  other  nodes  of  the 
acfg. 
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Now  the  user  wants  to  go  to  the  module  Angle,  the  only  program-defined 
module  called  from  the  main  module.  He  enters  the  string  "Angle"  in  the  WALKER 
input  area.  The  user  then  clicks  on  the  "Goto"  button.  He  is  in  the  Angle  module  at 
node  4,  line  13.  He  scrolls  the  text  window  to  display  the  Angle  function.  This  is  a 
begin-end  statement  so  the  user  goes  left  and  joins  nodes  4  and  5.  The  user  traverses  left 
several  times  until  he  reaches  node  IS.  The  statements  he  traverses  are  assignment 
statements.  If  the  analyst  desires,  the  effect  of  these  assignments  may  be  indicated  by 
modifying  the  reachability  conditions  or  SPACER  may  evaluate  the  effects  by  symbolic 
execution.  In  this  case,  the  latter  choice  is  made.  (See  Figure  3.7.) 

From  an  examination  of  the  code  in  the  text  subwindow,  the  user  finds 
he  is  at  the  beginning  of  a  series  of  assignment  statements.  Each  assignment  statement 
consists  of  a  function  call  and  the  assignment  of  the  result,  so  a  pair  of  nodes  represents 
each  line  of  code.  The  user  joins  these  node  together  as  pairs,  consisting  of  the  function 
call  and  the  assignment  of  the  result.  He  joins  nodes  15  and  16,  nodes  17  and  18,  nodes 
19  and  20,  nodes  21  and  22,  nodes  23  and  24,  nodes  25  and  26,  nodes  27  and  28,  and 
nodes  29  and  30,  traversing  left  between  the  join  operations.  The  analyst  could  proceed 
to  further  collapse  these  nodes  further,  reducing  a  linear  code  sequence  to  a  single  node, 
but  this  is  not  necessary  to  this  analysis. 

The  difficulty  in  processing  "if"  structures  lies  in  retaining  the  location 
in  the  code  and  the  context  of  that  location.  In  the  Angle  function,  there  are  several  "if” 
cases,  which  create  a  comblike  "if"  structure,  starting  with  node  31.  Only  one  of  these 
cases  will  happen  on  each  execution  of  Angle.  All  the  cases  gathci  together  at  the  end 
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Figure  3.7  WALK  WIN  Screen  While  Processing  Function  Angle 
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into  an  exit  node.  The  traversal  process  now  involves  forming  up  the  condition  that 
reaches  that  end.  The  user  needs  to  keep  track  of  each  of  these  "if"  cases.  Each  case 
has  an  immediate  condition  in  the  "if"  statement  and  implied  conditions  it  inherits  by 
being  the  "else"  of  the  previous  "if"  statements.  WALKER  does  some  automatic 
tracking  of  the  conditions,  but  the  user  may  need  to  intervene  to  simplify  conditions.  If 
the  conditions  are  too  complex,  it  can  cause  problems  in  later  processing.  SPACER  has 
a  limited  amount  of  memory  available,  and  the  text  has  a  limited  allowable  length. 

To  guide  this  simplification  process,  a  sketch  (such  as  Figure  3.8)  may 
be  used.  Later  extensions  of  WALKWIN  may  include  some  sketch  capabilities,  but  in 
the  prototype,  external  sketch  facilities  (e.g. ,  a  piece  of  paper)  must  be  used.  The  sketch 
includes  the  location  of  the  parameters  (XT,  YT)  and  reference  points  calculated  by 
Angle  from  the  parameters.  These  reference  points  (A,  B,  C,  D  on  Figure  3.8)  will  be 
referred  to  in  terms  of  their  X  and  Y  coordinates  (e.g.,  A  appears  as  AX  and  AY).  The 
observer  is  in  some  area  of  the  picture.  There  are  more  than  nine  cases  because  some 
are  exactly  on  the  lines,  some  are  between  lines  only,  and  some  include  both  lines  and 
the  area  in  between.  The  user  keeps  track  of  which  cases  he  covers. 

The  user  wants  to  systematically  traverse  the  "if"  structure.  He  will 
traverse  the  left  branch  first,  and  then  return  to  cover  the  right  branch  of  each  "if" 
statement.  The  first  "if"  statement  (node  31)  contains  the  condition  "(YO  >  BY)  and 
(XO  >  BX)",  so  this  area  is  in  the  upper  right  hand  area,  labeled  Case  1.  This  case 
does  not  include  the  lines,  because  it  is  strictly  greater  than.  The  user  goes  left  from 
node  31  and  finds  two  nodes  representing  a  function  call  and  an  assignment  of  the  result. 
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Figure  3.8  Sketch  for  getangle.p 

These  are  node  32,  which  is  the  call  to  the  "abs"  function,  and  node  33,  which  is  the 
assignment  to  the  variable  Angle.  The  user  notices  the  condition  is  no  longer  true.  It 
is  now  the  inequality  found  in  the  "if"  statement.  The  user  joins  nodes  32  and  33  to  drop 
out  the  pseudonode  call  to  the  abs  function.  The  user  goes  left  from  here  and  is  at  the 
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exit  node.  (See  Figure  3.9.)  This  is  a  pseudonode  created  when  REACHER  generated 
the  acfg.  Each  assignment  statement  could  be  the  last  statement  in  the  procedure. 
FALTER  and  SPACER  expect  one  exit  node.  So  if  there  isn’t  just  one  exit  node, 
WALKER  adds  an  exit  node  and  has  everything  that  looks  like  an  exit  node  goes  there. 
The  program  automatically  has  a  single  entry  node,  since  there  is  only  one  pointer  in 
each  header.  The  tools  do  not  handle  "goto"  statements,  so  there  is  only  one  way  into 
each  module.  Future  versions  of  the  tools  may  be  able  to  handle  "goto”  statements. 

The  last  node  visited  prior  to  the  exit  node  was  node  33.  To  continue 
the  traversal,  the  user  must  jump  back  to  the  node  corresponding  to  the  "if"  statement 
where  the  left  branch  was  taken.  That  was  node  31.  The  user  goes  to  node  31  using  the 
"Node"  command.  The  user  enters  the  number  of  the  node  he  desires  into  the 
"WALKER  input"  area,  and  clicks  on  the  "Node"  button.  Here  the  user  enters  "31"  and 
returns  to  the  "if"  statement.  The  user  goes  right  to  node  34.  The  user  goes  left  to  the 
body  of  the  "if'  statement  at  node  35.  The  condition  is  "anded"  onto  itself,  so  the  user 
simplifies  the  arc  condition  to  the  condition  of  the  "if"  statement  only.  He  enters  "((XO 
<  CX)  and  (YO  <  CY))"  in  the  "Walker  input"  area,  and  clicks  on  the  "Condition" 
button. 

This  duplication  is  the  result  of  coming  out  of  a  node  and  jumping  to  a 
node  rather  than  using  an  arc.  The  conditions  are  on  the  arcs  rather  than  on  the  nodes. 
When  the  user  jumps  out  and  returns  to  a  node,  there  is  no  condition  set.  This  condition 
is  a  copy  of  the  condition  in  the  "if"  statement  there.  The  user  notes  that  this  covers 
Case  2,  the  lower  left  hand  area.  The  condition  of  Case  2  implies  the  negation  of  the 
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conditions  of  Case  1  so  the  user  doesn’t  need  to  add  in  the  not  of  those  conditions.  The 
user  goes  left  to  node  35.  The  user  joins  nodes  35  and  36,  getting  rid  of  the  pseudo  call 
to  the  "abs"  function.  The  user  goes  left  and  arrives  at  the  exit  node. 

The  user  now  must  return  to  node  31  in  order  to  traverse  to  the  false 
branch  of  node  34.  He  returns  to  node  31  using  the  "Node"  button.  He  goes  right  from 
node  31  to  node  34  by  clicking  on  the  "Right"  button.  (See  Figure  3. 10.)  The  condition 
set  is  the  "not"  of  the  condition  in  the  "if"  statement  and  itself.  The  user  simplifies  the 
condition  by  eliminating  the  duplication.  The  user  goes  right  to  node  37.  The  user  sees 
that  this  is  Case  3,  where  "YO  >  AY  and  XO  <  AX"  and  it  doesn’t  include  the  line. 
He  enters  this  condition  for  node  37.  By  keeping  track  of  the  cases  already  covered,  the 
user  can  later  express  what  the  condition  is  in  a  certain  area  rather  than  what  it  is  not. 

The  user  wants  to  cover  both  branches  from  node  37.  He  goes  left  to 
node  38.  Again  he  simplifies  the  condition  to  "(YO  >  AY)  and  (XO  <  AX)".  The 
user  joins  nodes  38  and  39,  which  is  the  call  to  the  abs  function  and  the  assignment  of 
the  result.  The  user  now  goes  left  and  is  at  the  exit  node  again.  He  returns  to  node  37 
to  cover  the  right  branch.  The  user  simplifies  the  condition  by  setting  it  to  "((YO  > 
AY)  and  (XO  <  AX))".  The  user  goes  right  to  node  40  and  simplifies  the  condition. 
Here  the  "if"  condition  is  "YO  >  DY  and  XO  >  DX",  so  the  user  is  in  Case  4  of 
Figure  3.8.  The  condition  on  node  40  contains  duplication,  so  the  user  simplifies  the 
condition.  The  user  adds  in  the  two  conditions  to  make  one  simpler  condition. 

Node  40  has  both  a  left  and  right  branch.  The  user  goes  left  to  node  41 
and  simplifies  that  condition.  The  user  joins  nodes  41  and  42,  and  goes  left  to  the  exit 
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Figure  3.10  WALKWIN  Screen  With  Further  Node  Commands 
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node.  The  user  returns  to  node  40  and  simplifies  the  condition  by  setting  it  to  true. 
When  the  user  goes  right  to  node  43  WALKER  automatically  adds  in  the  not  of  the 
condition  ”XO  >  BX"  from  line  44.  The  user  already  eliminated  out  Cases  1  and  4  so 
the  condition  includes  "YO  <  =  DY";  he  adds  that  to  the  "if"  condition.  This  adds  in 
the  conditions  that  have  accumulated  so  far,  so  "XO  >  BX  and  YO  <  =  DY".  This  is 
Case  5.  The  user  goes  left  and  joins  nodes  44  and  45.  He  simplifies  the  condition  and 
goes  left  again  to  reach  the  exit  node. 

The  user  returns  to  node  43,  the  "if"  statement  for  "XO  >  BX",  to  cover 
the  right  branch  off  node  45.  Node  43’s  condition  is  too  complex,  so  the  user  simplifies 
it  to  "YO  >  =  DY  and  YO  <  =  BY".  He  goes  left  to  node  45  and  then  right  to  node 
46,  putting  himself  in  Case  6.  This  is  the  condition  where  "XO  <  AX"  and  Cases  2  and 
3  have  been  covered.  So  he  also  has  "YO  <  =  AY  and  YO  >  =  CY"  as  part  of  the 
condition  and  he  changes  the  condition  to  reflect  the  more  restrictive  of  the  two. 

From  node  46  there  is  a  left  branch  and  a  right  branch.  The  user  goes 
left  and  joins  nodes  47  and  48.  The  user  goes  left  and  is  at  the  exit  node.  The  user 
returns  to  node  46  and  this  time  goes  right  to  node  49.  He  has  the  condition  where  "YO 
>  =  AY"  so  it  is  the  case  of  the  line  AB  in  figure  3.4  and  everything  above  it.  Since 
the  user  already  traversed  Cases  1  and  3,  he  is  in  Case  7  of  the  diagram.  However,  the 
program  divides  Case  7  into  several  subcases.  So  the  user  can  set  some  limits  on  XO 
by  setting  the  context  for  YO  here.  It  is  not  pertinent  to  worry  about  excluding  the  parts 
previously  done.  Another  statement  on  AX  will  exclude  more  areas  later.  The  user  sets 
the  condition  to  true.  All  he  worries  about  is  setting  the  YO  condition  on  the  next  node. 
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The  user  goes  left  to  node  50.  Now  he  has  the  XO  set  up  so  if  "XO  =  AX"  and  the  "if" 
statement  is  true  he  is  on  the  line  AC  above  line  AB,  which  is  Case  7a  in  the  diagram. 
The  user  adds  the  comment  "XO  is  set  up".  The  user  goes  left  and  then  joins  nodes  51 
and  52.  The  user  goes  left  and  is  at  the  exit  node. 

The  user  returns  to  node  50  to  cover  the  right  branch.  He  handled  the 
body  of  the  first  double  "if"  so  he  goes  back  to  the  "XO  =  AX"  condition.  He  changes 
the  condition  to  "YO  >  =  AY".  The  user  goes  right  to  node  53.  He  knows  he’s  not 
on  the  line  and  "XO  <  BX"  is  the  condition  of  the  "if*  statement.  He  wants  to  simplify 
this  down  to  "XO  >  AX",  because  he  handled  the  paris  where  XO  <  AX  and  where 
XO  =  AX.  He  knows  XO  <  DX  so  he  is  not  on  the  line  BD,  but  is  between  the  lines 
in  Case  7b.  He  changes  the  condition  to  "(XO  >  AX)  and  (YO  >  =  AY)".  From  node 
53,  the  user  goes  left  to  node  54  where  there  is  a  call  to  the  "abs"  function.  Node  55 
is  also  a  call  to  the  "abs"  function"  and  node  56  assigns  the  result  of  "Pi  -  abs(SA)  - 
abs(SB)"  to  the  variable.  There  are  two  pseudonodes,  so  he  does  a  three  way  join.  The 
user  joins  nodes  55  and  56,  and  then  joins  nodes  54  and  56.  This  order  of  joining  keeps 
the  links  connected  and  avoids  the  loss  of  nodes.  The  user  goes  left  to  the  exit  node. 
(See  Figure  3.11.) 

The  user  returns  to  node  53  to  traverse  the  right  branch  from  the 
condition  "XO  <  BX"  in  the  "if"  statement.  He  simplifies  the  condition  of  node  53 
again.  The  user  now  goes  right  to  node  57,  and  is  under  the  else  condition  to  reach  Case 
7c.  The  user  has  dealt  with  the  line  AC  in  Figure  3.8  and  the  area  between  the  lines  AC 
and  BD  and  has  to  deal  with  the  portion  of  line  BD  above  line  AB.  He  does  some 
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Figure  3.11  WALKWIN  Screen  Showing  Multiple  Join 
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simplification  and  sets  the  condition  to  "XO  =  BX  and  YO  >  =  AY".  The  user  goes 
left  and  joins  nodes  57  and  58.  The  user  goes  left  to  the  exit  node. 

He  returns  to  node  49  to  traverse  the  right  branch  from  the  "if"  statement 
with  "YO  >  =  AY"  as  the  condition.  The  user  sets  the  condition  to  true  and  goes  right 
to  node  59,  so  "YO  <  =  CY".  The  user  is  now  in  Case  8.  Case  8  also  has  several 
subcases.  If  "YO  <  =  CY"  then  it  is  not  >  =  AY  so  the  user  sets  the  condition  to  true. 
The  user  then  goes  left  to  the  condition  "XO  =  DX"  at  node  60.  This  is  the  case  where 
the  observer  is  right  on  the  line  BD  in  Figure  3.8  and  is  in  Case  8a.  There  is  a  left  and 
right  branch  from  node  60.  The  user  goes  left  from  there.  Then  he  goes  left  again  and 
joins  nodes  61  and  62.  He  goes  left  again  and  reaches  the  exit  node.  The  user  goes 
back  to  the  "if'  statement  at  line  60  and  sets  the  condition  to  "YO  <  =  CY".  The  user 
goes  right  from  node  60  to  node  63  where  "XO  >  CX".  He  knows  here  that  in  addition 
to  "XO  >  CX",  that  "YO  <  =  CY"  and  "XO  <  DX".  He  has  handled  the  line  BD  in 
figure  3.8  and  is  in  the  middle  at  Case  8b.  The  user  simplifies  the  condition  to  "YO 
<  =  CY  and  XO  <  DX". 

Node  63  has  a  left  and  right  branch.  The  user  goes  left  to  node  64  and 
finds  another  triple  node  assignment.  He  joins  nodes  65  and  66,  and  then  joins  nodes 
64  and  66.  The  user  goes  left  to  the  exit  node.  The  user  returns  to  the  XO  >  CX  "if" 
statement  at  node  63  and  simplifies  the  condition  so  "YO  <  =  CY  and  XO  <  DX". 
The  user  goes  right  to  node  67.  He  is  down  in  the  assignment  statement,  so  he  joins 
nodes  67  and  68.  The  user  goes  left  and  is  at  the  exit  node. 
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The  user  has  to  cover  the  else  part  of  the  "YO  <  =  CY"  condition, 
which  is  node  55.  He  goes  to  node  59,  where  the  condition  is  "YO  <  =  CY".  The  user 
has  done  everything  except  the  internal  square,  Case  9.  So  he  knows  he  is  going  to  get 
the  not  of  the  condition  and  considers  the  previously  covered  cases.  He  changes  the 
condition  to  "YO  <  AY  and  XO  >  =  AX  and  XO  <  =  BX".  The  user  sets  the  upper 
limit  on  YO  and  the  two  limits  on  X.  This  case  includes  the  side  lines  but  not  the  top 
and  bottom  lines.  The  user  goes  right  to  node  69  and  is  in  the  angle  assignment.  He 
goes  left  to  the  exit  node  and  completes  the  traversal  of  the  Angle  module. 

There  is  one  module  left  to  traverse,  the  Slope  function.  The  user  goes 
to  the  Slope  function  using  the  "Goto"  button.  He  is  at  node  1,  and  joins  nodes  1  and 
2.  This  completes  the  traversal  of  "getangle.p". 

d.  Saving  work 

Once  the  user  finishes  traversing  the  graph,  he  needs  to  save  his  work. 
He  enters  the  filename  "walker  out"  in  the  WALKER  input  area  and  selects  the  "Walker 
Menu"  with  the  right  mouse  button.  He  highlights  the  "Save"  selection,  and  releases  the 
mouse  button.  (See  Figure  3.12.)  WALKER  writes  the  file  to  the  disk.  Appendix  G 
contains  a  copy  of  "walker_out".  This  does  not  exit  the  user  from  WALKER.  The  user 
now  selects  the  "Quit"  choice  from  the  "Walker  Menu".  This  ends  the  interaction  with 
WALKER  and  renders  the  buttons  and  menu  options  other  than  "Run"  inoperative. 
WALKWIN  sends  a  clear  command  to  the  tty  subwindow  to  clear  the  screen. 
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e.  Running  LISTER 

WALK  WIN  uses  the  button  labeled  LISTER  in  conjunction  with  the 
other  two  text  items  in  the  panel  to  get  the  annotated  source  listing.  The  user  enters  the 
input  filename  in  the  "Lister  input"  text  item,  in  this  case  the  filename  is  "reacher_out". 
To  activate  this  text  item,  he  moves  the  pointer  to  the  rectangle  containing  the  text  item, 
and  clicks  the  left  mouse  button.  The  movement  of  the  caret  to  the  end  of  the  label 
signals  that  it  is  active.  It  also  blinks.  The  user  activates  the  "Lister  output”  text  item 
and  enters  the  filename  desired.  He  chooses  "getangle.list"  as  the  name  for  the  output. 
He  moves  the  pointer  to  the  "Lister"  button  and  clicks  the  left  mouse  button.  (See 
Figure  3.13.)  The  tty  subwindow  displays  the  output  and  provides  feedback  that  LISTER 
saved  the  file.  Appendix  H  contains  a  copy  of  "getangle.list". 

This  concludes  the  portion  of  failure  region  analysis  done  via 
WALKWIN.  The  user  closes  the  frame  to  an  icon  or  exits  from  the  frame  using 
standard  SunView  menu  options. 

4.  FALTWIN 

a.  Initiating  FALTWIN 

The  user  displays  the  FALTER  interface  by  clicking  on  the  "Falter" 
button  in  the  VIEWWIN  panel  subwindow.  FALTWIN  can  use  the  same  filename  used 
by  REACHER,  or  another  text  file,  or  no  file  at  all.  Normally  FALTWIN  uses  the  same 
Pascal  file  used  by  WALKWIN,  so  the  filename  remains  in  the  text  entry  area. 
FALTWIN  displays  the  Pascal  file  in  its  text  subwindow  (just  like  WALKWIN). 
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Figure  3.13  WALKWIN  Screen  Showing  Call  To  LISTER 
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FALTWIN  has  more  panel  items  than  WALKWIN.  They  are  for  the 
additional  commands  used  with  FALTER.  (See  Figure  3.14.) 

b.  Traversing  the  graph  and  setting  the  fault 

The  directory  contains  the  files  reacher_out  and  walker_out.  The  user 
must  enter  a  filename  in  the  "Falter  input”  text  item.  He  indicates  the  output  saved  from 
WALKER  named  "walker_out"  in  the  "Falter  input"  area,  and  invokes  FALTER  by 
selecting  the  "Run"  choice  from  the  "Falter  Menu"  via  the  right  mouse  button.  FALTER 
loads  the  file  and  places  the  user  at  the  "readln”  statement  in  the  main  module  of  the 
"getangle.p"  program.  The  graph  representation  of  the  main  module  is  in  the  canvas 
sub  window. 

The  prompt  for  FALTER  is  different  from  WALKER.  It  has  some 
additional  fields.  The  prompt  is  the  text  of  the  line  under  consideration.  The  "1" 
is  the  local  condition.  The  "e"  prompt  shows  the  error  condition  (initially  ’false’)  and 
the  "c"  prompt  shows  any  comments  entered  by  the  user. 

Since  WALKER  has  set  up  all  the  reachability  conditions,  the  user  uses 
FALTER  to  record  what  the  fault  effect  will  be  and  the  conditions  under  which  that  fault 
will  occur.  The  user  will  normally  record  a  comment  about  the  fault.  FALTER  doesn’t 
really  do  any  analysis.  It  is  a  recording  mechanism,  allowing  the  user  to  traverse  the 
acfg  and  be  sure  he  is  where  he  wants  to  be.  The  process  requires  the  user  to  debug  the 
program  and  find  the  problem  prior  to  using  the  tools.  Now  he  defines  the  immediate 
effects  of  the  bug,  i.e.,  the  effects  on  the  next  state.  FALTER  represents  this  effect  by 
which  variable  values  are  contaminated.  SPACER  doesn’t  need  to  know  about  the  bad 
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value,  only  that  it  is  contaminated.  SPACER  assumes  that  if  the  value  is  contaminated 
and  the  failure  generation  condition  occurs  that  the  value  is  always  wrong.  The  user 
represents  this  in  the  error  generation  condition  and  identifies  which  variables  have  bad 
values. 

The  user  goes  to  the  Angle  module  using  the  "Falter  input  area"  to  enter 
the  text  "Angle"  and  clicking  on  the  "Goto"  button.  The  fault  in  "getangle.p"  is  in  case 
4.  The  SC  in  the  computation  "abs(SB  -  SC)"  under  the  condition  "YO  >  DY  and  XO 
>  DX"  is  wrong.  It  should  calculate  the  angle  between  points  B  and  D,  but  is  using 
points  B  and  C  instead.  In  certain  cases  the  angle  will  be  less  than  what  it  should  be. 
This  is  a  naturally  occurring  fault. 

The  user  wants  to  go  to  the  node  in  Case  4  where  the  fault  occurs.  He 
traverses  left  through  the  graph.  If  the  user  knew  the  node  number  automatically,  he 
wouldn’t  have  to  go  through  the  traversal.  Note  that  FALTER  doesn’t  make  any  changes 
until  the  user  tells  it  to  add  a  fault.  The  user  can  traverse  at  will  with  no  changes  made, 
unlike  WALKER  which  modifies  the  structure.  WALKER  can  go  left  and  right  without 
changing,  but  the  default  is  to  annotate  the  control  flow  graph  as  it  sets  up  reachability 
conditions. 

The  user  goes  left  from  the  nodes  until  he  reaches  the  first  "if"  statement 
where  "YO  >  BY  and  XO  >  BX".  He  goes  right  from  the  first  "if"  statement  and  right 
from  the  second  "if"  statement  where  "XO  <  CX  and  YO  <  CY".  He  goes  right  from 
the  third  "if"  statement  where  "YO  >  CY  and  XO  <  AX"  and  goes  left  from  the  fourth 
"if"  statement  where  "YO  >  DY  and  XO  >  DX".  This  is  Case  4  of  Figure  3.8.  He 
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has  found  the  bug  and  can  add  a  fault.  To  add  a  fault  the  user  clicks  on  the  "Add  Fault" 
button.  FALTER  identifies  this  fault  as  "Angle  1  type  13"  with  a  "#"  prompt.  (See 
Figure  3. 15.)  The  type  is  a  user  defined  field  to  allow  several  different  classes  of  faults. 
It  can  be  used  to  draw  statistics  about  the  failure  region  analysis. 

The  "Viol"  is  where  in  the  specification  the  violation  occurs.  This  is 
why  the  code  is  wrong.  This  bug  violated  "observation  condition  1"  of  the  specification 
of  the  program.  The  user  sets  the  violation  by  entering  the  text  into  the  "Falter  input" 
area  and  clicking  on  the  "Violation"  button.  The  "i"  prompt  is  for  the  implication  of  the 
fault.  The  implication  of  this  mis-assignment  is  the  variable  given  a  bad  value,  in  this 
case  "Angle."  The  user  sets  the  implication  by  entering  "Angle"  in  the  text  item  area 
and  clicking  on  the  "Implication"  button. 

The  error  generation  condition  is  currently  false.  The  user  sets  the  error 
condition  based  on  the  fact  that  the  programmer  used  SC  when  he  meant  to  use  SD. 
When  will  this  error  matter?  When  SC  and  SD  have  different  values.  When  will  that  not 
happen?  When  SC  and  SC  have  the  same  value,  which  would  be  when  observing 
something  with  a  zero  width.  It  is  possible  that  the  item  under  observation  may  have  a 
zero  width.  For  all  the  user  knows  that  is  legal.  Maybe  there  is  other  code  before  this 
that  would  prevent  it  but  the  user  doesn’t  know  that.  The  variable  "W"  is  the  value  of 
width  so  when  "W  <  >  0"  the  program  will  generate  an  error.  The  user  enters  the  text 
in  the  "Walker  input  string"  area  and  clicks  on  the  "Error"  button  to  set  the  error.  (See 
Figure  3.16.) 
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Figure  3.15  FALTWIN  Screen  Showing  Preparation  of  Fault  Annotation 
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Figure  3.16  FALTWIN  Screen  Showing  Fault  Annotation 
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The  user  can  annotate  the  acfg  and  record  a  comment  about  the  bug.  He 
enters  "mis-sub«titution  of  SC  for  SD  in  this  assignment"  in  the  text  input  area,  and 
clicks  on  the  "Annotation"  button. 

c.  Saving  work 

In  setting  up  these  fields,  FALTER  sets  some  of  them  directly  and  some 
of  them  in  temporary  variables.  The  user  wants  to  have  a  consistent  set  saved  to  internal 
memory  to  have  a  complete  record  of  the  fault.  The  user  can  save  the  fault  description 
in  two  ways.  (See  Figure  3.17.)  It  can  be  saved  in  Lisp  format  for  use  by  SPACER. 
The  user  enters  the  filename  in  the  "Falter  input"  text  item,  and  selects  "Save"  from  the 
"Falter  Menu"  button  via  the  right  mouse  button.  This  sets  the  current  error  condition 
to  match  the  temporary  values  displayed. 

The  file  also  can  be  saved  in  acfg  format  for  use  with  FALTER.  To 
save  a  file  in  acfg  format,  the  user  must  include  a  "-"  in  front  of  the  filename  he  enters 
in  the  "Falter  input"  area.  This  method  saves  the  acfg  so  the  user  can  read  it  back  into 
FALTER  and  work  with  it.  It  allows  the  user  to  have  several  fault  descriptions  for  the 
same  acfg.  The  user  could  compare  statistics  for  the  faults  in  the  file  if  there  are  other 
analysis  tools  to  read  acfg  format  statistics  on  failures  in  control  flow  graphs.  Currently 
these  types  of  tools  don’t  exist. 

The  user  saves  the  results  as  a  SPACER-usable  file  with  the  name 
"spacer_in.l".  The  user  selects  "Quit"  from  the  Falter  menu  to  end  the  interactive 
session  with  FALTER.  The  "spacer_in.l"  file  is  much  larger  than  the  "getangle.p" 
program.  Appendix  I  contains  a  copy  of  "spacer_in.l"  code.  The  "getangle.p"  code  is 
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Figure  3.17  FALTWIN  Screen  Showing  Save 
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74  lines,  and  "spacerjn.l"  is  541  lines.  (Reminder:  Appendix  E  contains  a  copy  of  the 
source  code  for  "getangle.p".) 

5.  SPACEWIN 

The  last  step  in  failure  region  analysis  is  SPACER.  SPACEWIN  allows  the 
user  to  invoke  LISP,  and  then  run  SPACER  using  the  output  from  FALTER.  More 
sophistication  in  SPACEWIN  is  an  area  for  future  development. 

The  user  copies  the  file  "spacerjn.l"  to  "temp.l"  since  SPACER  automatically 
loads  "temp.l"  during  processing.  A  copy  of  "getangle.p"  is  available  to  SPACER  as 
"temp.p"  in  the  directory.  SPACER  loads  the  files  then  prompts  the  user  to  select  the 
fault  to  be  generated  into  a  failure  region.  The  user  then  is  given  the  option  of  setting 
the  level  of  information  display  and  other  SPACER  options.  When  finished,  the  user 
types  "go"  and  SPACER  will  emulate  program  execution  to  generate  the  failure  region. 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 


A  well-organized  user  interface  contributes  to  the  efficiency  of  the  software  tester. 
Alleviating  the  requirements  to  recall  commands  and  providing  feedback  is  essential. 
The  use  of  graphics  and  a  windowing  environment  is  becoming  more  commonplace  in 
software. 

The  interface  can  provide  a  logical  organization  of  the  information  needed  by  and 
provided  to  the  tester.  The  ability  to  move  from  code  display  to  a  graphical 
representation  of  control  flow  is  useful. 

A.  CONCLUSIONS 

This  thesis  has  been  an  in-depth  examination  of  interface  design,  testing  tools,  and 
the  interaction  between  the  two.  It  also  is  the  first  development  of  a  graphical  user 
interface  for  the  failure  region  analysis  tools.  VIEWER  satisfies  many  of  the  design 
principles  for  interfaces.  It  presents  the  results  and  outputs  of  the  testing  tools  with 
consistency  and  coordination.  It  is  similar  to  other  tools  in  SunView,  so  it  retains  a  feel 
that  is  natural  to  SunView  users.  There  is  a  structure  to  the  interface,  while  maintaining 
a  degree  of  flexibility  for  the  tester. 

The  complexity  and  richness  of  the  SunView  language  allowed  rapid  construction 
of  a  prototype.  However,  further  refinements  and  enhancements  are  necessary. 
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B.  LESSONS  LEARNED 


Tools  can  represent  information  in  a  screen-oriented  way.  The  interface  can  key 
the  views  around  features  of  information  known  to  be  significant  in  the  testing  process. 
The  use  of  multiple  views  enhances  the  scope  of  the  tester’s  view  of  the  system  and 
allows  the  tester  to  detect  probl1  ms  in  the  analysis.  The  use  of  screen  orientation  reduces 
the  load  on  the  tester’s  memory. 

User  interface  design  should  be  a  part  of  the  tool  development  process.  If  the 
process  is  well  understood,  the  user  interface  design  may  be  highly  integrated  into  the 
development.  If  the  process  is  poorly  understood,  a  series  of  prototypes  may  be 
appropriate. 

Testing  is  a  relatively  new  area  of  research.  The  tools  used  in  testing  are  changing 
rapidly.  They  provide  information  to  the  user.  How  is  that  information  processed?  By 
the  user.  How  would  they  like  to  see  it  represented?  The  interface  may  show  graphs 
or  the  text  of  files.  A  simple  prototype  that  has  flexibility  allows  further  development 
and  improvement  as  the  tool  develops.  Useful  information  can  be  obscured  by  forcing 
it  into  an  interface  that  doesn’t  consider  fully  the  ramifications  of  the  information  on  the 
process  as  a  whole,  the  type  of  information  being  presented,  the  target  audience,  etc. 
The  interface  designer  shouldn’t  hesitate  to  use  a  textual  representation  of  data  until  a 
better  understanding  of  the  properties  of  the  data  and  desired  qualities  are  known.  Views 
must  be  focused  around  the  analysis-related  features,  or  the  interface  will  be  more 
distracting  than  helpful. 


92 


The  designer  should  consider  the  use  of  a  toolkit  such  as  SunView  when  designing 
a  graphical  user  interface.  The  toolkit  provides  a  high  level  language  to  manipulate 
objects  used  in  the  creation  of  the  interface.  This  enables  the  designer  to  maintain  a  level 
of  abstraction  during  the  design  process.  The  designer  has  to  be  aware  of  the  user’s 
needs  and  desires.  They  should  work  closely  with  the  user  to  incorporate  these  needs 
and  desires  into  the  interface.  The  interface  will  then  increase  productivity  instead  of 
increasing  frustration  in  the  user. 

C.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

Each  user  has  their  own  idea  of  a  "good"  interface.  To  allow  for  variations  in 
taste,  the  user  could  customize  the  interface  with  regard  to  size  and  placement.  Some 
may  feel  the  text  requires  a  larger  display  area,  while  others  may  not  want  to  use 
scrollbars,  but  see  the  entire  acfg  representation  at  once.  An  initialization  file  (.viewer) 
could  provide  unique  default  settings  for  the  VIEWER  interface  to  accommodate  a 
variety  of  users.  It  would  allow  tiling  of  the  windows  and  save  the  setup  to  a  file  so 
each  user  could  adjust  the  subwindows  to  suit  their  individual  preferences. 

We  designed  this  interface  on  a  Sun  Workstation  with  a  monochrome  display,  so 
color  was  not  a  consideration.  If  color  is  available,  the  use  of  color  in  the  design  of  user 
interfaces  is  a  direction  of  further  research.  Which  colors  work  best  together  as 
background  and  foreground,  text  representation,  and  window  colors  are  all  possibilities 
for  future  consideration.  This  use  of  color  could  include  the  interface  outline, 
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backgrounds  and  the  representation  of  the  acfg.  Nodes  could  be  color  coded  based  on 
their  type  (begin-end,  assignment,  etc.). 

Further  refinement  of  the  algorithms  that  construct  the  graphical  representation  of 
the  control  flow  graph  are  necessary.  Representing  complex  graphs  in  the  acfg  window 
is  a  complex  programming  problem  worthy  of  further  research  and  development. 

The  acfg  provides  another  area  of  research.  In  the  prototype  interface,  the  user  can 
display  the  graph,  but  it  is  non-interactive.  An  enhancement  allowing  traversal  of  the 
graph  through  use  of  the  mouse  would  be  useful  vice  the  button  facility  provided  in  the 
prototype.  While  the  buttons  are  useful,  and  in  some  ways  preferable  to  the  command 
line,  a  user  could  move  through  an  acfg  by  pointing  to  a  location  and  clicking  on  it. 

Error  handling  is  an  important  principle  in  the  design  of  user  interfaces.  The 
prototype  has  some  simple  error  handling  procedures.  There  is  much  room  for 
improvement  here.  The  program  could,  for  example,  check  for  the  existence  of  the 
filename  entered  before  running  any  program. 

The  interface  does  not  provide  on-line  help.  Help  only  exists  within  the  tools. 
Further  versions  of  the  interface  could  provide  more  detailed  help  facilities,  an  on-line 
manual,  etc. 

Levels  of  interface  support  are  another  possible  area  of  continued  research.  The 
program  could  detect  whether  the  user  is  a  beginner,  intermediate,  or  expert  and  provide 
different  interfaces  for  each  level.  The  beginner  level  would  provide  detailed  help 
functions,  and  prompt  the  user  with  detailed  explanations  of  what  the  program  expects 
at  various  junctures.  Artificial  intelligence  techniques  have  applications  here. 
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Other  languages  also  could  be  a  source  for  further  research.  SunView  is  a 
powerful  toolkit,  but  is  not  the  only  one  available  for  Sun  Workstations.  An  option 
provided  by  Sun  is  SunNeWS  (Sun  Network  extensible  Window  Systems).  It  uses  a 
version  of  PostScript  as  the  programming  language.  SunNeWS  can  support  graphical 
interfaces  to  remote  programs.  There  is  also  the  X  Window  System  that  originated  at 
MIT.  There  are  similarities  between  SunView  and  X  Windows,  but  X  Windows  also  can 
provide  an  interface  to  programs  on  remote  machines  like  SunNeWS.  (Beer,  p.  64) 
Follow-on  tools  to  use  the  results  from  VIEWER  are  an  area  of  further  research 
possibilities.  These  tools  could  analyze  the  relationships  between  failure  regions  within 
a  single  program  or  in  several  programs.  This  analysis  may  provide  information  on  the 
clustering  of  failure  regions  within  software.  Bolchoz,  1990  contains  several  additional 
ideas  for  further  research  in  the  area  of  failure  regions  analysis. 
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APPENDIX  A 


This  appendix  contains  the  text  from  an  interactive  session  with  the  EFFIGY  testing  tool. 
Italicized  text  indicates  comments. 


►  effigy 

EFFIGY  READY 

►  edit  absolute  effigy; 


NEW  FILE: 


Invoke  the  EFFIGY  system. 

Invoke  the  CMS  file  editor  and 
type-n  a  new  file  called 
"absolute  effigy". 


►  input 

►  absolute:  proc  (x,y); 

►  del  (x,y)  integer; 

►  if  x  <  O  then  y  =  -x 

►  else  y  =  x; 

►  end; 

►  file 

►  input  absolute  effigy; 


(end  of  input  signified  by  null  line.) 
Save  file  permanently  & 
go  back  to  EFFIGY. 


Have  EFFIGY  read  input  from 
that  file. 

1:  ABSOLUTE:  PROC(X,Y); 

2:  DCL  (X,Y)  INTEGER; 

Statements  are  numbered  by  EFFIGY. 

3:  IF  X<0  THEN  Y  =  -X 
4:  ELSE  Y  =  X; 

5:  END; 


►  del  z  integer; 

►  call  absolute  (55, z);  display  z; 


►  call  absolute  (-66, z);  display  z; 
66 

►  in  absolute;  turn  all  on  all; 


Last  line  of  file  -  back  to 
terminal  input. 

Declare  a  variable  in  MAIN. 

Try  a  numeric  execution. 
Result  of  display  statement. 
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All  tracing  on  in proc.  "absolute". 

►  in  main;  Set  back  to  main. 

►  call  absolute  (Ha",z); 

Try  a  symbolic  input  "a". 

1:  ABSOLUTE:  PROC  (X,Y); 

Each  statement  execution  is  traced 
by  printing  it. 

2:  DCL  (X,Y)  INTEGER; 

3:  IF  X  <  O  THEN  Y  =  -X 


((A  “»  >  -1))  Evaluated  result  ofX<  0-v(B). 

(A  <  ~1  or  A  <  0) 

TYPE  GO  TRUE  OR  GO  FALSE 

Unresolved  (forking)  IF— User  option. 

►  before  S;  Stop  before  executing  statement  5. 

►  save;  Save  the  current  execution  state. 

STATE  1  SAVED 

EFFIGY  calls  this  state  1. 

►  gO  true;  Follow  case  where  A<0. 

((A  — •  >  - 1 ))  Current  pc. 

TRUE  BRANCH 

Y  =  -A  Result  of  assignment  to  Y. 

STOPPED  BETWEEN  3  AND  5 

Stopped  "before  5". 

►  display  variables,  pc; 

All  local  values  and  the  pc. 

IN  ABSOLUTE 
X= A 
Y=-A 

((A  ~1  > -1))  Current  pc. 

►  restore  1 ;  Return  to  execution  state  1, 

and  try  else  path. 

STATE  1  RESTORED.  IN  ABSOLUTE 

►  go  false; 

((A-1  >•  1))  v(X<0). 

FALSE  BRANCH 
4:  ELSE  Y  =  X; 

Y = A  New  value  of  Y. 

STOPPED  BETWEEN  4  AND  5 


v(X<0). 


New  value  of  Y. 


►  display  variables,  pc; 
IN  ABSOLUTE 
X=A 

Y=A 

((Zi<0)) 

►  xgo; 


Before  5. 


Resume  execution  and  delete  breakpoint. 


BACK  FROM  ABSOLUTE  TO  MAIN 


97 


Reset  pc  to  true. 


►  display  z; 

A 

►  in  main; 

►  erase  pc; 

►  call  absolute("a"  -  "b",  z);  go  true; 
TYPE  GO  TRUE  OR  GO  FALSE 

►  display  z; 

-A+B 

►  edit  absolute  effigy; 

►  next 

►  change  /absolute/newabs/ 

►  bottom 

►  up  1 

►  input  assert(y  eq  abs(x)); 

►  file  newabs 

►  input  newabs  effigy; 


Go  true  above  anticipates  question. 


Invoke  editor  to  change  absolute. 

Edit  command  to  look  at  line  1  offile. 

Change  proc  name. 

Go  to  end  offile. 

Well  not  quite. 

Insert  a  correctness  specification. 

File  away  as  newabs  effigy. 

Go  back  to  EFFIGY. 

Enter  into  EFFIGY. 


1:  NEWABS:  PROC(X,Y); 

2:  DCL  (X,Y)  INTEGER; 

3:  IF  X<0  THEN  Y  =  -X 

4:  ELSE  Y  =  X; 

5:  ASSERT(Y  EQ  ABS  (X)); 

New  statement. 

6:  END; 

►  erase  pc; 

►  call  newabs("a",z);  go  true; 

TYPE  GO  TRUE  OR  GO  FALSE 


((abs(A)+A  =0))  ::  TRUE 


►  display  z,  pc; 

-A 

((A  > -1)) 

►  erase  pc; 

►  call  newabs("a",z);  go  false; 
TYPE  GO  TRUE  OR  GO  FALSE 


Response  was  anticipated  on 
previous  line. 

Result  of  executing  assert  (statement  5) 
Of  form  1  ::  r  where  .. 

I  is  evaluated  assertion  and 
r  is  result  of  pc  D  l. 

Value  ofz 
and  pc. 


Try  only  other  case. 
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((abs(A)-A  =0)) ::  TRUE 


That  also  gets  proved. 

Have  correctness  proof— both  paths 
correct. 

A 

((A-XO)) 

►  erase  pc; 

►  input  times  effigy; 

Now  read  in  procedure  times. 

1:  TIMES :PROC(X,Y,Z); 

2:  DCL  (X,Y,Z)  INTEGER; 

3:  Z=0; 

4:  IF  X<0  THEN 
4:  DO; 

5:  CALL  ABSOLUTE(X,X); 

Times  calls  absolute. 

6:  Y=-Y; 

7:  END; 

8:  L: 

8:  IF  X>0  THEN 

It  multiplies  by  looping  add. 

8:  DO; 

9:  X=X-1; 

10:  Z=Z+Y; 

11:  GOTOL; 

12:  END; 

13:  END; 

►  call  times  (3,5,z);  display  z; 

Try  some  numbers. 

15 

call  times(-3,5,z);  display  z; 

-15 

call  times(-34,"b",z);  display  z; 

A  mixed  case-determinate  control  flow. 

-34*B 

►  in  times;  turn  all  on  4  5  6  8  9  10; 

►  before  13;  in  main; 

►  call  timesCa",  "b",  z); 

The  completely  symbolic  case. 

4:  IF  X  <  0  THEN  DO; 

((A-o-l)) 

TYPE  GO  TRUE  OR  GO  FALSE 

►  save; 

STATE  2  SAVED 
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►  go  true; 

((Ai>-1)) 

TRUE  BRANCH 

5:  CALL  ABSOLUTE(X,X); 

Executed  a  resolved  IF  in  absolute. 
Knows  A<_-1. 

6:  Y  =  -Y; 

Y =-B 

8:  L:  IF  X  >  0  THEN  DO; 

((A-1  >-l)) 

TRUE  BRANCH 

Another  resolved  IF. 

A<-1  so  -A>0. 

9:  X  =  X  -  1; 

X=A-1 

10:  Z  =  Z  +  Y; 

Z=-B 

8:  L:  IF  X  >  0  THEN  DO; 

((A ->>-2)) 

TYPE  GO  TRUE  OR  GO  FALSE 

►  go  true; 

Loop  around. 

((Ai>-2)) 

TRUE  BRANCH 

9:  X  =  X  -  1; 

X=-A-2 

10:  Z  =  Z  +  Y; 

Z=-2*B 

8:  L:  IF  X  >  0  THEN  DO; 

((Z  ~ >  >  -3)) 

TYPE  GO  TRUE  OR  GO  FALSE 

►  go  false;  Now  go  out  to  end  qfproc. 

((A -.>-3)) 

FALSE  BRANCH 

STOPPED  BETWEEN  8  AND  13 

Breakpoint  at  end  qfproc. 

►  display  variables,  pc; 

IN  TIMES 
X=-A-2 

Y=-B 

Z=-2*B 

((A  =-2))  Path  choices  determine  A=-2. 

►  restore  2; 

STATE  2  RESTORED.  IN  TIMES 
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Try  another  case. 


►  go  false; 

((A-1  >-l)) 

FALSE  BRANCH 

8:  L  :  IF  X  >  0  THEN  DO; 

((A-1  <  1)) 

TYPE  GO  TRUE  OR  GO  FALSE 

►  assume("a"  >4); 

Add  this  assumption  to  the  pc. 

►  go;  Now  retry  die  IF  with  new  pc. 

((A-1  <  1)) 

TRUE  BRANCH  New  pc  resolves  it. 

9:  X  =  X  -  1; 

X=A-2 

10:  Z  =  Z  +  Y; 

Z=2*B 

8:  L:  IF  X  >  0  THEN  DO; 

((A-><3)) 

TRUE  BRANCH 

9:  X  =  X  -  1; 

X=A-3 

10:  Z  =  Z  +  Y; 

Z=3*B 

8:  L:  IF  X  >  0  THEN  DO; 

((A-K4)) 

TRUE  BRANCH 

9:  X  =  X  -  1; 

X=A-4 

10:  Z  =  Z  +  Y; 

Z=4*B 

8:  L:  IF  X  >  0  THEN  DO; 

((A  “» <  5)) 

TRUE  BRANCH 

9:  X  =  X  -  1; 

X=A-5 

10:  Z  =  Z  +  Y; 

Z=5*B 

8:  L:  IF  X  >  0  THEN  DO; 

((A-1  <6)) 

TYPE  GO  TRUE  OR  GO  FALSE 

Unresolved  when  X  gets  to  A-5. 

►  go  false;  Leave  loop. 

((A -<10)) 

FALSE  BRANCH 

STOPPED  BETWEEN  8  AND  13 
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►  display  variables,  pc; 
IN  TIMES 
X=A-5 


Y=B 

Z=5*B 


((A =5)) 

►  restore  2;  Go  back  and  try  another  case. 

STATE  2  RESTORED.  IN  TIMES 

►assume  ( "a"  eq  "b"  &  "b"  eq  2); 

Indirectly  assume  A  is  2. 

►  go;  Does  that  assume  resolve  the  if? 

((A-O-l)) 

FALSE  BRANCH  Yes  it  does. 

8:  L:  IF  X  >  0  THEN  DO; 

((A-1  <  1)) 

TRUE  BRANCH  This  one  resolved  too. 

9:  X  =  X  -  1; 

X=A-1 

10:  Z  =  Z  +  Y; 

Z=B 

8:  L:  IF  X  >  0  THEN  DO; 

((AK2)) 

TRUE  BRANCH  This  one  resolved  too. 

9:  X  =  X  -  1; 

X=A-2 

10:  Z  =  Z  +  Y; 

Z=2*B 


8:  L:  IF  X  >  0  THEN  DO; 
((A-1  <3)) 

FALSE  BRANCH 

STOPPED  BETWEEN  8  AND  13 
►  display  variables,  pc; 

IN  TIMES 
X=A-2 


Y=B 

Z=2*B 

((Z-B  =0&B  =2)) 

►  assert(a  eq  4); 

((B  =2))  ::  TRUE 

►go; 

► 

IN  MAIN 
►  next 


Result  still  in  symbolic  terms. 

Does  it  know  Z  is  really  4. 

Yes. 

Go  on  out  of  times. 

Response  to  previous  null  line. 
In  editor. 
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►  input 
►bottom 


assume(x  eq  "xO"  &  y  eq  "yO"); 

Insert  correctness  specifications. 


►  up  1 

►  input  assert  (z  eq  "xO"  *  "yO"); 

►  file 

►  erase  times; 


Replace  original  procedure 
and  go  bade  to  EFFIGY. 

Can 't  have  two  times  routines. 


►  erase  pc; 

►  input  times  effigy; 

Input  from  times  file. 

1:  TTMES:PROC(X,Y,Z); 

2:  ASSUME(X  EQ  "XO"  &  Y  EQ  "YO"); 

Used  to  name  input  values. 

3:  DCL  (X,Y,Z)  INTEGER; 

4:  Z=0; 

5:  IF  X<0  THEN 
5:  DO; 

6:  CALL  ABSOLUTE(X,X); 

7:  Y=-Y; 

8:  END; 

9:  L: 

9:  IF  X>0  THEN 
9:  DO; 

10:  X=X-1; 

11:  Z=Z+Y; 

12:  GO  TO  L; 

13:  END; 

14:  ASSERT(Z  EQ  "XO"  *  "YO"); 

Relate  input  values  to  output. 

15:  END; 

►  in  times;  turn  all  on  5  9  14; 

Selectively  trace. 

►  in  main; 

►  assume("a">4  &  "a"<5); 

No  integer  between  4  and  5. 

CONTRADICTING  ASSUMPTION.  IGNORED. 


►  assume("a">4  &  "a"<7); 

How  about  A  is  5  or  6. 

►  call  times("a",  "b",z); 

5:  IF  X  <  0  THEN  DO; 

((A-o-l)) 

FALSE  BRANCH 


For  5  and  6  X>0. 
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9:  L:  IF  X  >  O  THEN  DO; 
((A-.C1)) 

TRUE  BRANCH 

9:  L:  IF  X  >  O  THEN  DO; 

((A  “1  <  2)) 

TRUE  BRANCH 
9:  L:  IF  X  >  O  THEN  DO; 

((A  “-<3)) 

TRUE  BRANCH 
9:  L:  IF  X  >  O  THEN  DO; 
((A-l<4)) 

TRUE  BRANCH 
9:  L:  IF  X  >  O  THEN  DO; 
((A-1<5» 

TRUE  BRANCH 
9:  L:  IF  X  >  O  THEN  DO; 

((A --<6)) 

TYPE  GO  TRUE  OR  GO  FALSE 

GO  TRUE 

((A -.<6)) 

TRUE  BRANCH 
9:  L:  IF  X  >  O  THEN  DO; 
((A~'<7» 

FALSE  BRANCH 
14:  ASSERT(  Z  EQ  XO  *  YO); 
((6*B-0* Y 0=0)) ::  TRUE 

►  display  pc; 


((A =6  &  A-0=0  &  B-0=0)) 


►display  variables; 

IN  MAIN 

ABSOLUTE = PROC 


Z=6*B 

NEWABS = PROC 
TIMES  =  PROC 
►  quit 


For  5  and  6  loop  some  too. 


Now  must  decide  5  or  6. 
Pick  6. 


Known  not  >  6. 


Results  check  by  assert-O.K. 

What  is  the  pc? 

Relates  the  symbolic  inputs  to  the 
names  given  to  inputs  by  assume 
in  the  procedure. 

MAIN  has  variables  and  values  too. 


Value  ' PROC *  means  it  is  a  procedure. 


Leave  EFFIGY  system. 
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APPENDIX  B 


This  appendix  contain  .  the  script  from  an  interactive  session  with  the  ASSET  testing  tool. 


Script  started  on  Wed  Jun  13  12:08:55  1990 
%  asset 


j  ASSET  was  developed  with  the  support  of  the  National  Science  Foundation 
j  under  grant  CCR-8501614  and  the  Office  of  Naval  Research  under  contract 
!  N00014-85-K-414. 


Welcome  to  ASSET.  For  help  type  "help." 


Enter  relative  pathname  of  initial  default  directory. 

>>:.. 

>  >  > :  begin 

Enter  name  of  subject  procedure  file. 

>  > :  abel.p 

Separate  Compilation?  (Y/N)  [N] 

>  >:  n 

Enter  the  name  of  the  procedure  to  be  instrumented. 

If  you  would  like  to  be  prompted  with  the  names  of 

the  procedures  in  the  subject  program,  just  hit  carriage  return. 

>  >: 

=  =  >  Should  driver 
be  instrumented  for  testing?  (Y/N) 

>  >:  n 

=  =  >  Should  PositionUnit 
be  instrumented  for  testing?  (Y/N) 

>  >:  y 

>  >  > :  sel 

No  criterion  has  been  selected  yet. 
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SELECT  A  CRITERION 


A.  All-defs 

B.  All-c-uses 

C.  All-p-uses 

D.  All-c-uses/ some-p-uses 

E.  All-p-uses/ some-c-uses 

F.  All-uses 

G.  All-du-paths 

H.  All-edges 

Enter  letter  representing  the  selected  criterion 

>  >:  c 

Criterion  is  All-p-uses. 

>  >  > :  find 

>  >  > :  compile 
Compilation  begins  ... 

Done,  and  successful. 

>  >  > :  run 

Command  line  arguments?  (Y/N)  [Y] 

>  >:  n 

Executing  modified  subject  program  ... 

How  many  units?  1 

How  many  elements  in  unit  1?2 

What  x  y  position  for  unit  1?  (no  commas!)0.0  0.0 

How  many  elements/row  in  unit  1?1 

What  row  column  separation  for  unit  1?  (no  commas!)1.0  1.0 

What  Endurance  for  unit  1  element  1?1 

What  Endurance  for  unit  1  element  2?1 

Position[  1,  1]=(  0.0000,  0.5000) 

Position!  1,  2]=(  0.0000,  -0.5000) 

Enter  another  data  set?y 

How  many  units?  1 

How  many  elements  in  unit  174 

What  x  y  position  for  unit  1?  (no  commas!)0.0  0.0 

How  many  elements/row  in  unit  1?2 

What  row  column  separation  for  unit  1?  (no  commas!)!. 0  1.0 
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What  Endurance  for  unit  1  element  1?-1 
What  Endurance  for  unit  1  element  2?1 
What  Endurance  for  unit  1  element  3?-l 
What  Endurance  for  unit  1  element  4?1 
Position!  1,  1]=(  0.0000,  0.5000) 

Position!  1,  2]=(  -0.5000,  0.5000) 

Position!  1,  3]=(  0.0000,  0.0000) 

Position!  1,  4]=(  0.5000,  0.5000) 

Enter  another  data  set?y 

How  many  units?  1 

How  many  elements  in  unit  1?4 

What  x  y  position  for  unit  1?  (no  commas!)0.0  0.0 

How  many  elements/row  in  unit  1?2 

What  row  column  separation  for  unit  1?  (no  commas!)1.0  1.0 

What  Endurance  for  unit  1  element  1?1 

What  Endurance  for  unit  1  element  2?1 

What  Endurance  for  unit  1  element  3?0 

What  Endurance  for  unit  1  element  4?1 

Position!  1,  1]=(  -0.5000,  0.5000) 

Position!  1,  2]=(  0.5000,  0.5000) 

Position!  1,  3]=(  0.0000,  0.0000) 

Position!  1,  43— (  -0.5000,  -0.5000) 

Enter  another  data  set?n 

Do  you  want  to  run  the  subject  program 

on  some  additional  test  data?  (Y/N)  [N] 

>  >:  n 


>  >  > :  d~HcrHhc~Heh"Hck 
ALL-P-USES 

Still  need  to  exercise  all  of  the  following  of  def-clear  paths: 


with  respect  to 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 

Elements 


from  to 
1  (  2,  3) 

1  (  14,  15) 

1  (  15,  29) 

1  (  15,  16) 

1  (  17,  22) 

1  (  17,  18) 

1  (  23,  28) 

1  (  23,  24) 

1  (  30,  32) 

1  (  30,  31) 

1  (  32,  34) 
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Elements 

1 

( 32,  33) 

Elements 

1 

(  36,  41) 

Elements 

1 

(  36,  37) 

Elements 

1 

( 42,  47) 

Elements 

1 

( 42,  43) 

GRow 

1 

(  2,  3) 

Endurance 

1 

(  18,  20) 

Endurance 

1 

(  18,  19) 

Endurance 

1 

(  24,  26) 

Endurance 

1 

( 24,  25) 

Endurance 

1 

(  30,  32) 

Endurance 

1 

( 30,  31) 

Endurance 

1 

(  37,  39) 

Endurance 

1 

(  37,  38) 

Endurance 

1 

( 43,  45) 

Endurance 

1 

(  43,  44) 

Unit 

1 

(  2,  3) 

Unit 

1 

(  6,  14) 

Unit 

1 

(  8,  13) 

Unit 

1 

(  14,  49) 

Unit 

1 

(  14,  15) 

Unit 

1 

(  15,  29) 

Unit 

1 

(  15,  16) 

Unit 

1 

(  17,  22) 

Unit 

1 

(  17,  18) 

Unit 

1 

(  18,  20) 

Unit 

1 

(  18,  19) 

Unit 

1 

( 23,  28) 

Unit 

1 

(  23,  24) 

Unit 

1 

(  24,  26) 

Unit 

1 

(  24,  25) 

Unit 

1 

(  30,  32) 

Unit 

1 

( 30,  31) 

Unit 

1 

(  32,  34) 

Unit 

1 

(  32,  33) 

Unit 

1 

(  36,  41) 

Unit 

1 

(  36,  37) 

Unit 

1 

(  37,  39) 

Unit 

1 

( 37,  38) 

Unit 

1 

( 42,  47) 

Unit 

1 

(  42,  43) 

Unit 

1 

( 43,  45) 

Unit 

1 

(  43,  44) 
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mi 
T< 

T< 

T< 

T< 

T< 

T< 

T< 

T< 

T< 

T< 

T( 

T< 

T< 
TotalSq 
TotalSq 
row 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 
Unit 


(  14,  15) 
(  17,  22) 
(  17,  18) 
( 23,  28) 
(  23,  24) 
(  15,  29) 
(  15,  16) 
(  6,  14) 
(  14,  49) 
(  14,  15) 
(  17,  22) 
(  17,  18) 


( 23,  24) 
( 24,  26) 
( 24,  25) 


(  32,  34) 
(  32,  33) 
(  8,  13) 

(  14,  15) 
(  15,  29) 
(  15,  16) 
(  17,  22) 
(  17,  18) 
(  18,  20) 
(  18,  19) 
(  23,  28) 
(  23,  24) 
(  24,  26) 
( 24,  25) 
(  30,  32) 
( 30,  31) 
(  32,  34) 
(  32,  33) 
(  36,  41) 
(  36,  37) 
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Unit 

38 

(  36,  41) 

Unit 

38 

( 36,  37) 

Unit 

38 

(  37,  39) 

Unit 

38 

(  37,  38) 

Ill 


Unit 

38 

( 42,  47) 

Unit 

38 

( 42,  43) 

Unit 

38 

(  43,  45) 

Unit 

38 

( 43,  44) 

Squad 

38 

(  36,  41) 

Squad 

38 

( 36,  37) 

Squad 

38 

( 42,  47) 

Squad 

38 

(  42,  43) 

TotalSq 

40 

( 36,  41) 

TotalSq 

40 

(  36,  37) 

TotalSq 

40 

(  37,  39) 

TotalSq 

40 

(  37,  38) 

TotalSq 

40 

( 42,  47) 

TotalSq 

40 

( 42,  43) 

TotalSq 

40 

( 43,  45) 

TotalSq 

40 

(  43,  44) 

Unit 

44 

(  42,  47) 

Unit 

44 

(  42,  43) 

Unit 

44 

(  43,  45) 

Unit 

44 

( 43,  44) 

Squad 

44 

( 42,  47) 

Squad 

44 

( 42,  43) 

TotalSq 

46 

(  42,  47) 

TotalSq 

46 

( 42,  43) 

TotalSq 

46 

( 43,  45) 

TotalSq 

46 

( 43,  44) 

To  look  at  these  again  use  the  command  ’view  results’. 

>  >  > :  exit 
% 

script  done  on  Wed  Jun  13  12:32:51  1990 
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APPENDIX  C 


This  appendix  contains  the  script  from  an  interactive  session  with  the  Mothra  testing  tool. 


Script  started  on  Sun  Jun  17  18:51:09  1990 
%  mothra 


- + 


MOTHRA 


|  Fortran-77  Mutation  System  J 

i  i 

i  i 

j  Standard  Interface  | 

|  Version  1.5  | 

I  I 

H - h 


Please  enter  the  experiment  name:  [?](?)  jms2 
Ready  to  continue  a  mutation  experiment... 


*  ****  *  1)1**  *****  *  **  * 

Mothra  Main  Menu 
****************** 

(1)  Test  Case  Management  =  =  > 

(2)  Execution  Management  =  =  > 

(3)  GO!!! 

(4)  Status  Review  =  =  > 

(5)  View  Source  Code 

(6)  Exit  Mothra 
?  4 
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Status  Review  Menu 


(1)  View  Test  Status 

(2)  View  Status  Summary 

(3)  View  Mutant  Information  =  =  > 

?  1 


Working... 

24 ;  1 H?  1  h M/tmp/mut02699 1 "  [Read  only]  34  lines,  2079  characters  ;H2J 
PERCENTAGE  OF  VERIFIED  TEST  CASES  0.096H 

Type  Genr’d  Enabled  Live  %Live  Equiv  Dead  %Enable  %EScore  %GScore 


abs 

12 

12 

5 

41.7 

0 

7 

100.0 

58.3 

58.3 

aor 

6 

6 

0 

0.0 

0 

6 

100.0 

100.0 

100.0 

crp 

6 

6 

1 

16.7 

0 

5 

100.0 

83.3 

83.3 

csr 

4 

4 

0 

0.0 

0 

4 

100.0 

100.0 

100.0 

der 

1 

1 

0 

0.0 

0 

1 

100.0 

100.0 

100.0 

san 

3 

3 

0 

0.0 

0 

3 

100.0 

100.0 

100.0 

scr 

8 

8 

3 

37.5 

0 

5 

100.0 

62.5 

62.5 

sdl 

3 

3 

1 

33.3 

0 

2 

100.0 

66.7 

66.7 

svr 

12 

12 

1 

8.3 

0 

11 

100.0 

91.7 

91.7 

uoi 

9 

9 

0 

0.0 

0 

9 

100.0 

100.0 

100.0 

Totals 

64 

64 

11 

17.2 

0 

53 

100.0  82.8 

82.! 

Class  Genr’d  Enabled  Live  %Live  Equiv  Dead  %Enable  %EScore  %GScore 


ary  0  0  0  0.0  0  0  0.0  0.0  0.0 

con  8  8  3  37.5  0  5  100.0  62.5  62.5 

ctl  1  1  0  0.0  0  1  100.0  100.0  100.0 

dmn  27  27  6  22.2  0  21  100.0  77.8  77.8H 

24;lH7tmp/mut026991"  [Read  only]  34  lines,  2079  characters!!  H 
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KAopm 

6  6 

0 

0.0  0 

6 

100.0 

100.0 

100.0 

Aprd 

0  0 

0 

0.0  0 

0 

0.0 

0.0 

0.0 

Ascl 

16  16 

1 

6.3  0 

15 

100.0 

93.8 

93.8 

Astm 

6  6 

1 

16.7  0 

5 

100.0 

83.3 

83.3 

A 

ASuperCl 

Genr’d  Enabled  Live  %Live 

Equiv 

Dead 

%  Enable  %EScore 

%GScore 

A 

A - 

A 


Aall 

64 

64 

11 

17.2 

0 

53 

100.0 

82.8 

82.8 

Acca 

30 

30 

4 

13.3 

0 

26 

100.0 

86.7 

86.7 

Apda 

27 

27 

6 

22.2 

0 

21 

100.0 

77.8 

77.8 

A  sal 

7 

7 

1 

14.3 

0 

6 

100.0 

85.7 

85.7 

?AHAAHK7mNo  previous  regular  expressionm 


K?ll 


Status  Review  Menu 


(1)  View  Test  Status 

(2)  View  Status  Summary 

(3)  View  Mutant  Information  =  =  > 

?  2 


Working... 

24;lH?lh"/tmp/mut026991"  [Read  only]  21  lines,  632  characters  ;H2J 
PERCENTAGE  OF  VERIFIED  TEST  CASES  0.0%4;21HSummary  for  Experiment 
jms2 


Number  of  Test  Cases  =  30 

Number  of  Test  Cases  Verified  =  0 

Number  of  Mutants  Enabled  =  64 

Number  of  Mutants  Generated  =  64 

Number  of  Live  Enabled  Mutants  =  11 

Number  of  Dead  Enabled  Mutants  =  53 

Number  of  Equiv  Enabled  Mutants  =  0 
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%  Non-equivalent  Enabled  Mutants  Killed  =  82.81 

%  Non-equivalent  Generated  Mutants  killed  =  82.81 

#  of  Mutants  Types  Remaining  to  be  Generated  =  0  out  of  22 


~  H24;  lH7tmp/mut02699r  [Read  only]  21  lines,  632  characters!! 


Status  Review  Menu 


(1)  View  Test  Status 

(2)  View  Status  Summary 

(3)  View  Mutant  Information  =  =  > 

?  3 


Mutant  Information  Menu 


(1)  View  Inline  Mutant  Information 

(2)  Browse/Equivalence  Mutants 

(3)  Histograms 
?  3 


Mutant  Types:  [[+,-]type,?](all)  all 
Histogram  Parameters:  [[+,-]ldes?](live,equiv) 


Working... 

24;lH?lh'7tmp/mut02699r  [Read  only]  17  lines,  440  characters  ;H2J 


24;1HK?11 
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PERCENTAGE  OF  VERIFIED  TEST  CASES  0.0% 


Histogram  of  Live/Equivalent  Mutants 


Frequency  335 

5  * 

4  * 

3  *  *  * 

2  *  *  * 

1  *  *  * 


Statement  12  3 


-  H24;  lH7tmp/mut02699 1 "  [Read  only]  17  lines,  440  charactersH24;lHK?ll 


Mutant  Information  Menu 


(1)  View  Inline  Mutant  Information 

(2)  Browse/Equivalence  Mutants 

(3)  Histograms 
?  1 


Mutant  Types:  [[+,-]type,#,?](all) 

Inline  Parameters:  [[+,-] lde?] (live , equiv) 


Working... 

24;lH?lh"/tmp/mut02699  r  34  lines,  971  characters  ;H2J 


SUM 


ft  Type  Mutant  # 
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c 

c 


Sum  - 

Computes  the  sum  of  N  integers 


PROGRAM  SUM 

INTEGER  N,  RESULT 

C  Loop  through  values  and  compute  sum 
1  RESULT  =  0 


tt 

sdl 

41 

tt 

CONTINUE 

it 

svr 

45 

tt 

I  =  0 

it 

scr 

34 

it 

RESULT  =  I 

2 

DO 

10  I  =  1,  N,  1 

it 

crp 

21 

it 

DO  10  I  =  0 

H24;lH7tmp/mut026991"  34  lines,  971  characters!! 


KA#  scr 
A#  scr 
A3 

A#  abs 
A#  abs 
Aft  abs 
A#  abs 
A#  abs 
A 
A4 
A5 
?11 


36  #  DO  10  I  =  RESULT,  N,  1 

37  tt  DO  10  I  =  I,  N,  1 

RESULT  =  RESULT  +  I 
4  tt  RESULT  =  ABS  (RESULT)  +  I 

7  tt  RESULT  =  RESULT  +  ABS  (I) 

9  it  RESULT  =  RESULT  +  ZPUSH(I) 

10  it  RESULT  =  ABS  (RESULT  +  I) 

12  #  RESULT  =  ZPUSH(RESULT  +  I) 

10  CONTINUE 
END 


Mutant  Information  Menu 


(1)  View  Inline  Mutant  Information 

(2)  Browse/Equivalence  Mutants 

(3)  Histograms 
12 


Mutant  Types:  [[+,-]type,0,?](all) 

Browse  Parameters:  [[+,-]lder?](live,equiv, sorted) 
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Working... 

Note  that  no  equivalent  mutants  currently  exist. 
Sorting... 

Browsing  11  mutants... 

Filling  the  browse  buffer... 

Mutant  number  45  is  live: 

1  RESULT  =  0 

#  svr  45  ft  1  =  0 

Command:  [ln#euq?](next) 


Mutant  number  41  is  live: 

1  RESULT  =  0 

#  sdl  41  ft  CONTINUE 

Command:  Pn#euq?](next) 


Mutant  number  34  is  live: 

1  RESULT  =  0 

ft  scr  34  ft  RESULT  =  I 

Command:  [ln#euq?](next) 


Mutant  number  21  is  live: 

2  DO  10  I  =  1,  N,  1 

ft  crp  21  if  DO  10  I  =  0,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  36  is  live: 

2  DO  10 1  =  1,  N,  1 

ft  scr  36  ft  DO  10  I  =  RESULT,  N,  1 

Command:  [ln#euq?](next) 
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Mutant  number  37  is  live: 


2  DO  10  I  =  1,  N,  1 

#  scr  37  tt  DO  10  I  =  I,  N,  1 

Command:  [ln#euq?](next) 


Mutant  number  4  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  4  tt  RESULT  =  ABS (RESULT)  +  I 

Command:  [ln#euq?](next) 


Mutant  number  9  is  live: 

3  RESULT  =  RESULT  +  I 

#  abs  9  tt  RESULT  =  RESULT  +  ZPUSH(I) 

Command:  [ln#euq?](next) 


Mutant  number  7  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  7  tt  RESULT  =  RESULT  +  ABS(I) 

Command:  [ln#euq?](next) 


Mutant  number  10  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  10  tt  RESULT  =  ABS  (RESULT  +  I) 

Command:  pn#euq?](next) 

Refilling  the  browse  buffer... 
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Mutant  number  12  is  live: 


3  RESULT  =  RESULT  +  I 

ft  abs  12  ft  RESULT  =  ZPUSH(RESULT  +  I) 

Command:  Pn#euq?](next) 

Mutant  number  45  is  live: 

1  RESULT  =  0 

ft  svr  45  ft  1  =  0 

Command:  [ln#euq?](next) 

Mutant  number  41  is  live: 

1  RESULT  =  0 

#  sdl  41  ft  CONTINUE 

Command:  Pn#euq?](next) 

Mutant  number  34  is  live: 

1  RESULT  =  0 

#  scr  34  ft  RESULT  =  I 

Command:  Pn#euq?](next) 

Mutant  number  21  is  live: 

2  DO  10  I  =  1,  N,  1 

ft  crp  21  ft  DO  10  I  =  0,  N,  1 

Command:  Pn#euq?](next) 

Mutant  number  36  is  live: 

2  DO  101  =  1,  N,  1 

ft  scr  36  ft  DO  10  I  =  RESULT,  N,  1 
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Command:  [ln#euq?](next) 


Mutant  number  37  is  live: 

2  DO  10 1  =  1,  N,  1 

#  scr  37  #  DO  10  I  =  I,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  4  is  live: 

3  RESULT  =  RESULT  +  I 

#  abs  4  it  RESULT  =  ABS  (RESULT)  +  I 

Command:  [ln#euq?](next) 

Mutant  number  9  is  live: 

3  RESULT  =  RESULT  +  I 

labs  9  tt  RESULT  =  RESULT  +  ZPUSH(I) 

Command:  [ln#euq?](next) 

Mutant  number  7  is  live: 

3  RESULT  =  RESULT  +  I 

labs  7  it  RESULT  =  RESULT  +  ABS  (I) 

Command:  Dn0euq?](next) 

Mutant  number  10  is  live: 

3  RESULT  =  RESULT  +  I 

it  abs  10  #  RESULT  =  ABS  (RESULT  +  I) 

Command:  Pn#euq?](next) 
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Mutant  number  12  is  live: 


3  RESULT  =  RESULT  +  I 

#  abs  12  #  RESULT  =  ZPUSH(RESULT  +  I) 

Command:  [ln#euq?](next) 

Mutant  number  45  is  live: 

1  RESULT  =  C 

#svr  45  #  1  =  0 

Command:  pn#euq?](next) 

Mutant  number  41  is  live: 

1  RESULT  =  0 

#  sdl  41  tt  CONTINUE 

Command:  [ln#euq?](next) 

Mutant  number  34  is  live: 

1  RESULT  =  0 

#  scr  34  it  RESULT  =  I 

Command:  Qn#euq?](next) 

Mutant  number  21  is  live: 

2  DO  10  1  =  1,  N,  1 

it  crp  21  it  DO  10  I  =  0,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  36  is  live: 

2  DO  10  I  =  1,  N,  1 
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#  scr  36  #  DO  10  I  =  RESULT,  N,  1 

Command:  Pn#euq?](next) 

Mutant  number  37  is  live: 

2  DO  10  I  =  1,  N,  1 

#  scr  37  #  DO  10  I  =  I,  N,  1 

Command:  Pn#euq?](next) 

Mutant  number  4  is  live: 

3  RESULT  =  RESULT  +  I 

#  abs  4  #  RESULT  =  ABS (RESULT)  +  I 

Command:  [ln#euq?](next) 

Mutant  number  9  is  live: 

3  RESULT  =  RESULT  +  1 

tf  abs  9  it  RESULT  =  RESULT  +  ZPUSH(I) 

Command:  [ln#euq?](next) 


Mutant  number  7  is  live: 

3  RESULT  =  RESULT  +  I 

it  abs  7  if  RESULT  =  RESULT  +  ABS (I) 

Command:  Pn#euq?](next) 

Mutant  number  10  is  live: 

3  RESULT  =  RESULT  +  I 

it  abs  10  it  RESULT  =  ABS  (RESULT  +  I) 

Command:  Pn#euq?](next) 
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Mutant  number  12  is  live: 


3  RESULT  =  RESULT  +  I 

ft  abs  12  #  RESULT  =  ZPUSH(RESULT  +  I) 

Command:  [ln#euq?](next) 

Mutant  number  45  is  live: 

1  RESULT  =  0 

#svr  45  #  1  =  0 

Command:  Pn#euq?](next) 

Mutant  number  41  is  live: 

1  RESULT  =  0 

it  sdl  41  it  CONTINUE 

Command:  [ln#euq?](next) 

Mutant  number  34  is  live: 

1  RESULT  =  0 

it  scr  34  it  RESULT  =  I 

Command:  [ln#euq?](next) 

Mutant  number  21  is  live: 

2  DO  10  1  =  1,  N,  1 

if  crp  21  #  DO  10  I  =  0,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  36  is  live: 

2  DO  10  I  =  1,  N,  1 
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tt  scr  36 


tt  DO  10  I  =  RESULT,  N,  1 


Command:  [ln#euq?](next) 

Mutant  number  37  is  live: 

2  DO  101  =  1,  N,  1 

tt  scr  37  tt  DO  10  I  =  I,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  4  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  4  tt  RESULT  =  ABS  (RESULT)  +  I 

Command:  [ln#euq?](next) 


Mutant  number  9  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  9  tt  RESULT  =  RESULT  +  ZPUSH(I) 

Command:  [ln#euq?](next) 

Mutant  number  7  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  7  tt  RESULT  =  RESULT  +  ABS(I) 

Command:  [ln#euq?](next) 


Mutant  number  10  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  10  tt  RESULT  =  ABS  (RESULT  +  I) 

Command:  [ln#euq?](next) 
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Mutant  number  12  is  live: 


3  RESULT  =  RESULT  +  I 

#  abs  12  #  RESULT  =  ZPUSH(RESULT  +  I) 

Command:  Pn#euq?](next) 

Mutant  number  45  is  live: 

1  RESULT  =  0 

#  svr  45  #  1  =  0 

Command:  Pn#euq?](next) 

Mutant  number  41  is  live: 

1  RESULT  =  0 

it  sdl  41  it  CONTINUE 

Command:  [ln#euq?](next) 

Mutant  number  34  is  live: 

1  RESULT  =  0 

#  scr  34  #  RESULT  =  I 

Command:  pn#euq?](next) 

Mutant  number  21  is  live: 

2  DO  10  I  =  1,  N,  1 

it  crp  21  it  DO  10  I  =  0,  N,  1 

Command:  pn#euq?](next) 


Mutant  number  36  is  live: 

2  DO  10  I  =  1,  N,  1 

it  scr  36  it  DO  10  I  =  RESULT,  N,  1 
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Command:  Pn#euq?](next) 


Mutant  number  37  is  live: 

2  DO  10  I  =  1,  N,  1 

it  scr  37  ft  DO  10  I  =  I,  N,  1 

Command:  [ln#euq?](next) 

Mutant  number  4  is  live: 

3  RESULT  =  RESULT  +  I 

#  abs  4  ft  RESULT  =  ABS (RESULT)  +  I 

Command:  pn#euq?](next) 

Mutant  number  9  is  live: 

3  RESULT  =  RESULT  +  I 

tt  abs  9  ft  RESULT  =  RESULT  +  ZPUSH(I) 

Command:  [ln#euq?](next) 

Mutant  number  7  is  live: 

3  RESULT  =  RESULT  +  I 

ft  abs  7  ft  RESULT  =  RESULT  +  ABS (I) 

Command:  pn#euq?](next) 

Mutant  number  10  is  live: 

3  RESULT  =  RESULT  +  I 

if  abs  10  ft  RESULT  =  ABS  (RESULT  +  I) 

Command:  Pn#euq?](next) 

Mutant  number  12  is  live: 
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3  RESULT  =  RESULT  +  I 

tt  abs  12  tt  RESULT  =  ZPUSH(RESULT  +  I) 

Command:  [ln#euq?](next) 

Mutant  number  45  is  live: 

1  RESULT  =  0 

#  svr  45  tt  1  =  0 

Command:  [ln#euq?](next) 

Mutant  number  41  is  live: 

1  RESULT  =  0 

tt  sdl  41  tt  CONTINUE 

Command:  [ln#euq?](next)  q 


Mutant  Information  Menu 


(1)  View  Inline  Mutant  Information 

(2)  Browse/Equivalence  Mutants 

(3)  Histograms 
?  , 


****************** 

Mothra  Main  Menu 
****************** 

=  =  > 
=  =  > 

> 


(1)  Test  Case  Management 

(2)  Execution  Management 

(3)  GO!!! 

(4)  Status  Review 

(5)  View  Source  Code 

(6)  Exit  Mothra 
?  5 


Working... 
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24 ;  1 H?  1  h "/ tmp/mut02699 1 "  [Read  only]  21  lines,  350  characters  ;H2J 


SUM 


C  Sum  - 

C  Computes  the  sum  of  N  integers 


PROGRAM  SUM 
INTEGER  N,  RESULT 

C  Loop  through  values  and  compute  sum 

1  RESULT  =  0 

2  DO  10  I  =  1,  N,  1 

3  RESULT  =  RESULT  +  I 

4  10  CONTINUE 

5  END 

~  H24; lH"/tmp/mut026991 "  [Read  only]  21  lines,  350  charactersH24;lHK?ll 

****************** 

Mothra  Main  Menu 
****************** 

(1)  Test  Case  Management 

(2)  Execution  Management 

(3)  GO!!! 

(4)  Status  Review 

(5)  View  Source  Code 

(6)  Exit  Mothra 
?  6 


No  test  cases  have  been  deleted. 

Saving  experiment  jms2... 

Exiting  mothra...  bye. 

%  exit 
% 

script  done  on  Sun  Jun  17  18:54:46  1990 
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APPENDIX  D 


This  appendix  contains  source  code  for  the  programs  used  in  VIEWER.  Each  portion 
of  code  contains  a  short  header  with  the  title  and  a  description  of  the  code. 


/*  Makefile  */ 

CC  =  cc 

all:  walkwin  viewwin  faltwin 

walkwin:  walkwin.c  ablock.o  acfg.o  walker.h  acfg.h  ablock.h 

$(CC)  -DHIGHRES  -DDEBUG  -DREADACFG  -DACFGGRAPH  -g  -o  walkwin 
walkwin.c  ablock.o  acfg.o  -lsuntool  -lpixrect  -lsunwindow  -lm 

viewwin:  viewwin.c 

$(CC)  -g  -o  viewwin  viewwin.c  -lsuntool  -lpixrect  -lsunwindow 
faltwin:  faltwin.c 

$(CC)  -DHIGHRES  -DDEBUG  -DREADACFG  -DACFGGRAPH  -g  -o  faltwin 
faltwin.c  ablock.o  acfg.o  -lsuntool  -lpixrect  -lsunwindow  -lm 

spacewin:  space  win.  c 

$(CC)  -g  -o  spacewin  spacewin.c  -lsuntool  -lpixrect  -lsunwindow 

ablock.o:  ablock.c  walker.h  acfg.h 
$(CC)  -c  -g  ablock.c 

acfg.o:  acfg.c  walker.h 
$(CC)  -c  -g  acfg.c 
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/*  TITLE 

*  AUTHORS 

*  DATE 

*  REVISED 

*  SYSTEM 

*  LANGUAGE 

*  COMPILER 

*  DESCRIPTION 


:  viewwin.c 

:  Vicki  Abel  and  Medio  Monti 
:  15  September  90 
:  29  October  90 
:  NPS  SUN  TAURUS 
:  SunView  and  C 
:  Unix  cc 

:  This  program  creates  the  viewer  frame.  This  frame 

*  consists  of  a  Tty  subwindow  and  a  control  panel.  The  user  enters  a  filename  to  be 

*  processed.  There  are  buttons  to  call  REA  CHER  on  the  file,  as  well  as  the 

*  interfaces  REACHWIN,  FALTWIN,  and  SPACEWIN. 

*/ 


/*  SunView  header  files  needed  for  the  program  */ 

^include  <  suntool/sunview.h  > 

^include  <suntool/tty.h> 

^include  <  suntool/icon.h  > 

^include  <suntool/scrollbar.h> 

^include  <  suntool/panel.h  > 

^include  <suntool/alert.h> 

^include  <stdio.h> 

/*  type  declarations  */ 

Frame  baseframe; 

Tty  tty_sw; 

Panel  panel; 

Panel_item  filename_item;  /*  This  is  for  the  filename  input  */ 

Icon  viewer_icon; 


I*  Default  window  sizes  for  HIGHRES  SCREEN  */ 


^define  TTYWINHEIGHT  794 

^define  TTYWINWIDTH  5 1 1 

^define  PANEL WINHEIGHT  100 

^define  PANELWINWIDTH  5 1 1 

^define  PANELWINX  0 


/*  These  are  notify  procedures  for  the  buttons  */ 

static  void  call_walker(); 

static  void  call_faltwinO; 

static  void  call_spacewin(); 

static  void  file_procQ; 
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/*  loading  icon  image  into  array  */ 
static  short  iconjmagefl  =  { 
^include  "viewer.icon" 


}; 


/*  Sun  View  macro  for  importing  an  icon  into  the  program  */ 
mpr_static(icon_pixrect,  64,  64,  1,  iconjmage); 

/•Main  */ 


main(argc,  argv) 
int  argc; 

char  •argvO; 

{ 

/•  file  name  =  argv[l];  not  used  */ 

viewer_icon  =  icon_create(ICON_IMAGE,  &icon_pixrect,  0); 


/*  this  is  the  base  frame  for  the  application  •/ 
baseframe  =  window_create( 

NULL,  FRAME, 

WINX,  0,  /•  sets  x  position  relative  to  owner  •/ 
WIN  Y,  205,  /*  sets  y  position  relative  to  owner  •/ 

FRAME_LABEL,  "Viewer  1.0",  /*  frame  label  */ 
FRAME  ICON,  viewer  icon,  /•  icon  used  •/ 
FRAME  ARGS,  argc,  argv,  /•  main  args  •/ 


/•  this  is  a  tty  subwindow  */ 
tty  sw  =  window  create(base  frame,  TTY, 
WIN  HEIGHT,  TTYWINHEIGHT, 
WIN  WIDTH,  TTYWINWIDTH 


/*  this  is  a  button  subwindow  •/ 
panel  =  window_create( 
base  frame,  PANEL, 

WIN  BELOW,  tty_sw, 

WIN  HEIGHT,  PANELWINHEIGHT, 
WIN~WIDTH,  PANELWINWIDTH, 
WIN  X,  PANELWINX, 
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/*  This  is  the  Filename  input  area  */ 

/*  Filename  is  limited  to  50  characters  */ 

filename  item  =  panel  create  item( 
panel,  PANEL  TEXT, 

PANEL  LABEL_STRING,  "Filename:", 

panel"value_display  LENGTH,  50, 

0); 

/*  this  is  a  button  for  calling  WALKER  */ 

/*  and  then  calls  REACHWIN  */ 
panel_create_item( 

panel,  PANEL  BUTTON, 

PANELNOTIF  YPROC ,  call_walker, 
PANEL_LABEL_IMAGE,  panel_button_image  ( 
panel,  "Walter",  0,  0), 

0); 

/*  this  is  a  button  for  calling  FALTWIN  *1 
panel_create_item( 

panel,  PANEL  BUTTON, 

PANELNOTIF  YPROC ,  call_faltwin, 

PANEL  LABEL  IMAGE,  panel  button  image  ( 
panel,  "Falter",  0,  0), 

0); 

/*  this  is  a  button  for  calling  SPACEWIN  */ 
panel_create_item( 

panel,  PANEL  BUTTON, 

PANELNOTIF  YPROC ,  call_spacewin, 
PANEL_LABEL_IMAGE,  panel_button_image  ( 
panel,  "Spacer",  0,  0), 

0); 

window_fit(base_frame) ; 
window_main_loop(base_frame) ; 
exit(0); 
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/*  Process  to  call  REACHER  and  WALKWIN  */ 
static  void 
call  walkerO 
{ 

char  tmp_buf[81); 

Event  event; 

int  result; 

sprintf(tmp_buf,  "%s",  panel_jet_value(filename_item)); 

/*  Check  for  "p"  as  last  character.  */ 

/*  Simple  test  for  Pascal  file.  */ 

if(tmp_buf[strlen(tmp_ouf)- 1]  ==  ’p’)  { 

/*  call  REACHER  on  the  filename  entered  by  user  */ 
sprintf(tmp_buf,  "reacher  %&  &\n",  panel jget_value(filename_item)) ; 
ttysw_input(tty_sw,  tmp  buf,  strlen(tmp_buf)); 

/*  call  WALKWIN  with  filename  as  argument  */ 

sprintf(tmp_buf,  "walkwin  %s  &\n",  panel^e^valueffilenamejtem)); 

ttysw_input(tty_sw,  tmp  buf,  strlen(tmp  buO); 

} 


/*  file  name  does  not  end  in  "p"  */ 
else  { 

msgCImproper  filename.",  1); 
panel_set_value(filename_item ,  " ; 
return; 

} 

} 
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/*  Procedure  to  pop  up  alert  frame  with  message  about  improper  */ 

/*  filename.  Called  by  call_walker.  */ 
msg(msg,  beep) 
char  *msg; 
int  beep; 

{ 

int  result; 

Event  event; 

char  *continue_msg  =  "Press  \"Continue\"  to  proceed."; 
result  =  alert_prompt(base_frame ,  &event,ALERT_MESSAGE_STRINGS,  msg, 
continue_msg,  0,  ALERT  NO  BEEPING,  (beep)  ?  0:1, 

ALERT  BUTTON  YES ,  ""Continue" ,  0); 

/*  only  one  option  for  the  user  */ 
switch  (result)  { 

case  ALERT  YES: 
break; 

} 


/*  Procedure  to  call  FALTWIN.  Uses  filename  in 
*  filename  item. 

*/ 


static  void 
callfaltwinO 

{ 

char  tmp_buf[81]; 

sprintf(tmp_buf,  "faltwin  %s  &Vn",  panel_get_value(filename_item)) ; 
ttysw_input(tty_sw,  tmp_buf,  strlen(tmp_buO); 

} 


/*  Procedure  to  call  SPACEWIN.  */ 
static  void 
callspacewinO 
{ 

char  tmp_buf[81]; 

sprintf(tmp_buf,  "spacewin  &\n",  panel_get_value(filename_item)); 
ttysw_input(tty_sw,  tmp_buf,  strlen(tmp_buf)); 
panel  set_value(filename  item,  ""); 

} 
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/♦TITLE 

♦  AUTHORS 
♦DATE 
♦REVISED 

♦  SYSTEM 

♦  LANGUAGE 

♦  COMPILER 


:  walkwin.c 

:  Vicki  Abel  and  Medio  Monti 
:  5  October  1990 
:  12  December  1990 
:  NPS  SUN  TAURUS 
:  SunView  and  C 
:  Unix  cc 

*  DESCRIPTION  :  This  program  is  the  interface  for  the  failure  region 

*  testing  tool  WALKER.  Chapter  n  contains  all  the  pertinent  details  relating 

*  to  this  code. 

*/ 


/♦  SunView  header  files  needed  in  this  program.  */ 

#define  MAIN  /♦  Necessary  for  the  acfg  graph  ♦/ 
include  <suntool/sunview.h> 

#include  <suntool/panel.h> 

^include  <suntool/textsw.h> 

#include  <suntool/tty.h> 
include  <suntool/canvas.h> 

^include  <suntool/icon.h> 

#include  <suntool/scrollbar.h> 

^include  <  pixrect/pr  line.  h  > 

^include  <stdio.h> 

^include  <math.h> 

/♦  These  macros  contain  declarations  necessary  for  drawing  the 

*  acfg  graph.  These  header  files  are  from  Dr.  Shimeall’s  testing 

*  tools. 

♦/ 

#ifdef  ACFGGRAPH 
^include  "walker,  h" 

^include  "ablock.h" 

^include  "acfg.h" 
include  XDISP  50 
#endif  ACFGGRAPH 


^define  NUM  POINTS 
^define  XDONE 
^define  YDONE 
^define  XSTART 
^define  YSTART 
^define  POSMAX 


1000  /*  Results  in  a  smooth  circle  ♦/ 
200 
200 


200  /*  Graph  staring  point  */ 
200  /♦  Graph  starting  point  */ 
200 
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/*  Presently  necessary  for  defining  a  high  resolution  screen  */ 

#ifdef  HIGHRES 

^define  STARTX 

200 

^define  STARTY 

50 

#define  RADIUS 

10 

^define  BASEFRAMEX 

525 

#define  BASEFRAMEY 

205 

^define  ACFGHEIGHT 

794 

» 

^define  ACFGWIDTH 

500 

^define  CANVASHEIGHT 

1400 

^define  CANVASWIDTH 

900 

^define  TEXTWINHEIGHT 

394 

^define  TEXTWINWIDTH 

495 

^define  TTYWINHEIGHT 

394 

^define  TTYWINWIDTH 

495 

^define  PANEL WINHEIGHT 

100 

^define  PANELWINWIDTH 

1000 

^define  PANELXGAP 

10 

^define  FONT 

1 

#define  XDISP 

25 

^define  YDISP 
#endif  HIGHRES 

25 

/*  Presently  necessary  for  defining  low  resolution  screens  */ 
lifdef  LOWRES 

^define  STARTX 

150 

- 

^define  STARTY 

25 

^define  RADIUS 

5 

^define  BASEFRAMEX 

365 

^define  BASEFRAMEY 

163 

^define  ACFGHEIGHT 

476 

^define  ACFGWIDTH 

350 

^define  CANVASHEIGHT 

540 

^define  CANVASWIDTH 

890 

^define  TEXTWINHEIGHT 

236 

^define  TEXTWINWIDTH 

347 

^define  TTYWINHEIGHT 

236 

^define  TTYWINWIDTH 

347 

^define  PANELWINHEIGHT 

100 

^define  PANELWINWIDTH 

702 

^define  PANELXGAP 

5 

- 

^define  FONT 

0 

^define  XDISP 

15 

- 
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^define  YDISP 
#endif  LOWRES 


12 


/*  these  define  pixrect  ptrs  */ 
^define  NULLPR  ((Pixrect  *)  0) 


/*  vlist  is  an  array  of  structures  pr_pos  for  the  circle  */ 
static  struct  pr__pos  vlistO[NUM_POINTS]; 


/*  Sun  View  type  declarations  */ 
Frame  base_ffame; 

Panel  control_panel; 

Canvas  acfg_canvas; 

Textsw  textsw; 

Panelitem  walkermenu; 

Panel_item  walker_input_string; 
Panelitem  listerinputstring; 

Panel_item  listeroutputstring; 

Tty  ttysw; 

Pixfont  "‘bold; 

Pixfont  "‘controlfont; 


Pixwin  *pw;  /^pixwin  object  */ 
int  i,  j;  /*  Loop  variables  */ 


/*  Initializing  graph  variables  *1 

int  startxval  =  XSTART; 

int  startyval  =  YSTART; 

int  finishxval  =  XDONE; 

int  finishyval  =  YDONE; 

float  angle;  /*  for  circle  computations  */ 

float  increment;  /*  for  circle  computations  */ 

int  counter  =  0;  /*  for  circle  computations  */ 

int  walkerrun  =  0; 

char  *file_name;  /*  Name  of  file  to  load  into  text  subwindow  */ 


fifdef  ACFGGRAPH 

FILE  *infile;  /*  Logical  file  name  for  acfg  graph  */ 
#e  ndif  ACFGGRAPH 
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#ifdef  ACFGGRAPH 

/*  Graph  object  declarations  */ 

int  curx; 

int  cury; 

int  finalx; 

int  finaly; 

int  rootid; 

/*  structure  for  an  (x,y)  coordinate  */ 
typedef  struct 
{ 

int  x; 
int  y; 

}POINT; 

/*  Array  of  the  above  structures  */ 

POINT  position[POSMAX]; 

int  TOS  =  0;  /*  Top  of  Stack  */ 

acfg  *cumode;  /*ptr  to  acfg  */ 

ahbkref  curblock;  /*ptr  to  hdr  structure  */ 

acfg  *stack[POSMAX] ;  /’•‘stack  of  acfg  structures  */ 

#endif  ACFGGRAPH 

/*  SunView  declarations  for  Icons  */ 

Icon  walkericon; 

Icon  walkermenuicon; 

/*  Procedures  used  by  buttons  and  menus  */ 

static  void  call  annotateO; 

static  void  caII_changeO; 

static  void  callJoinO; 

static  void  call_goto(); 

static  void  call_priorO; 

static  void  call  leftO; 

static  void  call  rightO; 

static  void  call_node0; 

static  void  call_typeO; 

static  void  walker jprocO; 

static  void  lister_proc(); 

#ifdef  ACFGGRAPH 

static  void  drawlineO;  /*  For  drawing  arcs  between  nodes  */ 

static  void  drawcircleO;  /*  For  drawing  the  nodes  */ 

#endif  ACFGGRAPH 
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/*  This  is  the  icon  for  the  frame  */ 
static  short  iconjmageO  =  { 

^include  "walker.icon" 

}; 

/*  mpr_static  is  a  SunView  macro  that  imports  an  icon  into  the  program*/ 
mpr_static(icon_pixrect,  64,  64,  1,  icon_image); 

/*  This  icon  was  created  to  allow  differentiation  between  a  button 

*  with  a  related  menu  and  a  simple  button.  It  is  used  for  the 

*  menu  for  interaction  with  WALKER. 

*/ 

static  short  walkerarrayQ  =  { 

^include  "walkermenu.icon" 

}; 

mpi_static(walker_pixrect,  64,  64,  1,  walker_array); 

//define  ADDEDEXITNODE  999999 
int  shifts[POSMAX]; 

void 

subtreeshift(root,disp) 
acfg  *root; 
int  disp; 

{ 

if  (root  -  =  NULL)  return; 

if  (root-  >  acfgnum  ==  ADDED_EXIT_NODE)  return; 
shifts[root->acfgnum  -  rootid]  +=  disp; 
subtreeshift(root-  >  acfglft,  disp); 
subtreeshift(root-  >  acfgrt.disp); 


int  calcoffsets(root) 
acfg  *root; 


int  leftval,  rightval; 
if  (root=  =NULL)  return  0; 

if  (root-  >  marked  =  =  1)  return  0;  /*  crossovers  possible  */ 
root-  >  marked  =  1; 

if  (root-  >  acfgnum  ==  ADDED_EXIT_N ODE)  ( 
shifts[POSMAX- 1]  =0; 

} 

else  { 
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shifts[root->acfgnum  -  rootid]  =  0; 

} 

if  (root-  >  acfglft  ==  NULL)  return  0; 
if  (root-  >  acfgrt  =  =  NULL)  return  calcoffsets(root->  acfglft); 
leftval  =  calcoffsets(root->  acfglft); 
rightval  =  calcoffsets(root->  acfgrt); 
if  (leftval  >0) 
if  (rightval  >0)  { 

subtreeshift(root-  >  acfglft,  -  (leftval + rightval +l)/2); 
subtreeshift(root-  >  acfgrt,  (leftval + rightval  + l)/2); 

} 

else  { 

subtreeshift(root->  acfgrt,  1  +  leftval/2); 
subtreeshift(root-  >  acfglft,  -( 1 + leftval/2)) ; 

} 

else  { 

subtreeshift(root->  acfglft,  -  (rightval  -I-  2)/2); 
subtreeshift(root-  >  acfgrt,  (rightval + 2)/2) ; 

} 

return  (int)  1 . 5  *(leftval + rightval)  + 1 ; 


void 

drawgraph(root) 
acfg  ’"root; 

{ 

int  done  draw  =  0; 
cumode  =  root; 
rootid  =  root->acfgnum; 
curx  =  STARTX; 
cury  =  STARTY; 


calcoffsets(root); 

cleamode(root); 


pw_writebackground(pw,0,0, 

(pw-  >  pw_pixrect)-  >  pr_size.x,(pw-  >  pw_pixrect)-  >  pr_size.y,PIX_CLR); 
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do  { 

#ifdef  DEBUG 

printf("  Drawing  node  %d  (%d)  into  pos  %d\n" ,  cumode-  >  acfgnum, 
cumode, cumode-  >  acfgnum-rootid); 

#endif  DEBUG 


if  (cumode  =  =  NULL)  { 

printf("  ran  off  edge  of  graph\n"); 
break; 

} 

if(cumode->acfgrt  !=  NULL)  { 

#ifdef  DEBUG 

printf("  Pushing  node  %d  (%d)  into  stack  %d\n",cumode-> acfgnum, cumode, TOS); 
#endif  DEBUG 

stack[TOS]  =  cumode; 

TOS+  +  ; 

finalx  =  curx  -  XDISP  + 

((cumode-  >  acfglft-  >  marked  =  =  1)  ?  0  : 

((cumode- >acfglft->  acfgnum  =  =  ADDED  EXIT  NODE)  ?  0  : 
shifts[cumode-  >  acfglft-  >  acfgnum-rootid])); 
f  naly  =  cury  +  YDISP; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 

if  (cumode- >  acfgnum  ==  ADDED_EXIT_N ODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX-l].y  =  cury; 

} 

else  { 

position[cumode->  acfgnum-rootid].  x  =  curx; 
position[cumode- >  acfgnum-rootid].  y  =  cury; 
curx  =  finalx; 
cury  =  finaly; 
cumode- >  marked  =  1; 

#ifdef  DEBUG 

printf("  Advancing  left  to  node  %d\n", cumode- >  acfglft); 
j^endif  DEBUG 

cumode  =  cumode- >  acfglft; 
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} 

} 

else  if(cumode->acfglft  ==  NULL  &&  TOS>0)  { 

#ifdef  DEBUG 

printf("  Popping  node  %d  (%d)  from  stack  %d\n",stack[TOS-l]- > acfgnum, 
stack[TOS-l],TOS-l); 

#endif  DEBUG 

TOS-; 

cumode  =  stack[TOS]; 
finalx  =  curx  +  XDISP  + 

((cumode-  >  acfgrt-  >  marked  =  =  1)  ?  0  : 

((cumode-  >acfgrt->  acfgnum  =  =  ADDED_EXITJNODE)  ?  0 
shifts[cumode-  >  acfgrt-  >  acfgnum-roodd])); 
finaly  =  cury  +  YDISP; 

if  (cumode- >  acfgnum  =  =  ADDED_EXIT_NODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX-l].y  =  cury; 
drawcircle(curx,  cury); 

} 

else  { 

position[cumode->acfgnum-rootid].x  =  curx; 
positionjcumode- >  acfgnum-roodd].  y  =  cury; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 
curx  =  finalx; 
cury  =  finaly; 

#ifdef  DEBUG 

printf("  Advancing  right  to  node  % d\n", cumode- > acfgrt); 
tfendif  DEBUG 

cumode  =  cumode- >  acfgrt; 

} 

} 

else  if  (cumode- >acfglft  !=  NULL)  { 

if  (cumode- >  acfgnum  !=  ADDED_EXIT_NODE)  { 

#ifdef  DEBUG 

printf("  Advancing  down  to  node  %d\n" , cumode- >acfglft); 

#endif  DEBUG 


144 


cumode  =  cumode- >  acfglft; 

finalx  =  curx; 

finaly  =  cury  +  YDISP; 

if  (cumode-  >  acfgnum  ==  ADDEDEXITNODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX-l].y  =  cury; 
drawcircle(curx,  cury); 

} 

else  { 

position[cumode->acfgnum-rootid].x  =  curx; 
position[cumode->acfgnum-rootid].y  =  cury; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 
cury  =  finaly; 

} 

} 

else  {done  draw  =  1;} 

} 

if  (cumode!  =NULL) 

while((!done_draw)  && 

((cumode-  >  acfgnum  =  =  ADDED_EXIT_NODE)  |  j  (cumode- >  marked 

=  =  D) 

&&  (TOS  >  0))  { 

#ifdef  DEBUG 

printf("  Popping  node  %d  (%d)  f  .n  stack  %d\n",stack[TOS-l]-> acfgnum, 
stack[TOS-l],TOS-l); 

#endif  DEBUG 

cumode  =  stack[TOS-l]; 

if  (cumode  ==  NULL)  {done_draw=l;  cumode = root;  break;} 
if  (cumode-  >  acfgnum  =  =  ADDED  EXIT  NODE)  { 
curx  =  position[POSMAX].x; 
cury  =  position[POSMAX].y; 

} 

else  { 

curx  =  position[cumode->acfgnum-rootid).x; 
cury  =  position[cumode->acfgnum-rootid].y; 

} 

if  (cumode- >acfgrt  ==  NULL)  {done_draw=  1;  break;} 
finalx  =  curx  +  XDISP  + 

((cumode-  >  acfgrt-  >  marked  =  =  1)  ?  0  : 


145 


((cumode-  >  acfgrt-  >  acfgnum  ==  ADDEDEXITNODE)  ?  0 
shifts[cumode-  >  acfgrt-  >  acfgnum-rootid])); 
finaly  =  cury  +  YDISP; 
drawline(curx,  cury,  finalx,  finaly); 
curx  =  finalx; 
cury  =  finaly; 

#ifdef  DEBUG 

printf(H  Advancing  remaining  link  to  node  %d\n",  cumode- > acfgrt); 
lendif  DEBUG 

cumode  =  cumode- >  acfgrt; 

TOS --; 

} 

else  {donedraw  =  1; 
cumode  =  root; 

} 

}  while  (!done_draw  &&  ((cumode- >  acfglft  !=  NULL)  |  j 
(cumode- >  acfgrt  !=  NULL)  [  j 
(TOS  >  0))); 

if  (!done_draw)  drawcircle(curx,  cury); 

} 

/*  Main  */ 

main(argc,  argv) 
int  argc; 
char  *argvO; 

{ 

/♦  This  is  the  acfg  window  test  procedure  */ 

/*  It  can  be  deleted  in  future  versions  */ 
fifdef  MYGRAPH 

static  int  npts[l]  =  {NUM  POINTS}; 

#endif  MYGRAPH 

tffdef  DEBUG 
printf("started  main\n"); 

#endif  DEBUG 

/*  assign  second  item  of  input  line  to  file_name  to  display  it  */ 

/*  in  the  text  subwindow  */ 
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file_name  =  argv[l]; 


#ifdef  DEBUG 

printf("starting  to  initialize  windows\n"); 

#endif  DEBUG 

walker_icon  =  icon_create(ICON_IMAGE,  &icon_pixrect,  0); 

/*  this  is  the  base  frame  for  the  application  */ 
base  frame  =  windo w_create(NULL ,  FRAME, 

WIN_X,  BASEFRAMEX,  /*  sets  x  position  relative  to  owner  */ 
WIN_Y,  BASEFRAMEY,  /*  sets  y  position  relative  to  owner  */ 
FRAMELABEL,  "Walker  Window  2.4",  /*  frame  label  */ 
FRAME  ICON,  walker_icon,  /*  icon  used  */ 

FRAME  ARGS,  argc,  argv,  /*  main  args  */ 

0); 

/*  this  is  a  canvas  subwindow  */ 
acfg  canvas  =  window_create(base_frame,  CANVAS, 
WINHEIGHT,  ACFGHEIGHT, 

WIN  WIDTH,  ACFG WIDTH, 

C ANV AS  AUTO  EXP AND ,  FALSE, 
CANVAS_AUTO_SHRINK,  FALSE, 

CANVAS  WIDTH,  CANVASWIDTH, 

CANVAS  HEIGHT,  CANVASHEIGHT, 

WIN  VERTICAL  SCROLLBAR,  scroUbar_create( 
SCROLL_PLACEMENT,  SCROLL_WEST, 
SCROLL_PAGE_BUTTONS,  FALSE, 

0), 

WIN  HORIZONTAL  SCROLLBAR,  scrollbar  createf 
SCROLL_PLACEMENT,  SCROLL_SOUTH, 
SCROLL_PAGE_BUTTONS ,  FALSE, 

0), 

0); 

#ifdef  ACFGGRAPH 
#ifdef  DEBUG 

printf("Ready  to  start  graph. c\n"); 

#endif  DEBUG 

/* - graph.c  main  code - */ 

/*  reacher_out  is  where  we  find  the  textual  representation  of  the 

*  control  flow  graph.  We  must  put  it  into  the  logical  file  to  use 

*  use  it. 
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*/ 

infile  =  fopen("reacher  out",  "r"); 
if  (infile  ==  NULL)  {” 

fprintf(stderr,"No  reacher_out  file\n"); 
exit(l); 

} 

ahlen  =  0; 

/*  Dynamically  allocate  memory  for  the  logical  file  and  put  it  into 

*  memory.  The  function  readreacher  is  part  of  the  failure  region 

*  testing  tools.  We  used  it  with  our  program  with  Dr.  Shimeall’s 

*  permission. 

*/ 

while(!feof(infile))  { 
int  i; 

ahlen+  +  ; 
i  =  sizeof(ahbkref); 

if(ahlen  >  1)  ( 

ahprocs  =  (ahbkhdr  **)MYREALLOC(ahprocs,  ahlen  *i); 

} 

else  { 

ahprocs  =  (ahbkhdr  **)  MYALLOC(i); 

} 


"'(ahprocs  +  ahlen- 1)  =  allocahbkO; 
readreacher(infile,  "‘(ahprocs  +  ahlen-1)); 

} 

#ifdef  DEBUG 

printf("Ready  to  draw  graph\n"); 

#endif  DEBUG 
/*  initialize  */ 


curblock  =  •‘(ahprocs  +  ahlen-1); 
cumode  =  (curblock- >abkgrph); 
if  (cumode  =  =  NULL)  { 

fprintf(stderr,"No  nodes  in  reacher_out  main  block\n"); 
exit(l); 

} 

/*  Define  pw  and  set  up  circle  coordinates  */ 
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pw  =  canvas__pixwin(acfg_canvas); 
increment  =  2  *  M_PI  /  NUM_POINTS; 
for(angle  =  0;  angle  <  (2  *  M_PI);  angle  +  =  increment)  { 
vlistO[counter].x  =  RADIUS  *  cos(angle); 
vlistO[counter].y  =  RADIUS  *  sin(angle); 
counter++; 

} 

drawgraph(curblock-  >  abkgrph); 
fifdef  DEBUG 

printf("Ready  to  initialize  graphics  panel\n"); 

#endif  DEBUG 

#endif  ACFGGRAPH 

#ifdef  MYACFG 

pw  =  canvasjpixwin(acfg_canvas); 

/*  Draw  the  circle  */ 
increment  =  2  *  M_PI  /  NUM_POINTS; 
for(angle  =  0;  angle  <  (2  *  M_PI);  angle  +  =  increment)  { 
vlistO[counter].x  =  RADIUS  *  cos(angle); 
vlistO[counter].y  =  RADIUS  *  sin(angle); 
counter+  +  ; 


I*  This  construct  is  designed  to  draw  a  vector,  then  to  load  an 

*  array  with  the  points  to  use  to  draw  the  circle,  and  the  same 

*  points  are  used  to  draw  the  lines  around  the  polygon. 

*/ 

for(j  =  1;  j  <  6;  j  +  +)  { 

pw_vector(pw,  startxval,  startyval,  finishxval,  finishyval, 

PIX_SRC,  1); 

pw_polygon  2(pw,  startxval,  startyval,  1,  npts,  vlistO, 

PIX_CLR,  NULLPR,  0,  0); 

for(i  =  0;  i  <  (NUM_POINTS  -  1);  i++)  { 

pw_vector(pw,  vlist0[i].x  +  startxval,  vlist0[i].y  + 
startyval,  vlist0[i+l].x  +  startxval,  vlist0[i+l].y  + 
startyval,  PIX  SRC,  1); 

} 

pw_vector(pw,  vlistO[NUM_POINTS  -l].x  +  startxval, 
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vlistO[NUM_POINTS  -l].y  +  startyval, 
vlist0[0].x  +  startxval,  vlist0[0].y  +  startyval, 

PIX_SRC,  1); 

startyval  =  finishyval; 
finishyval  +  =  YSTART; 

} 

#endif  MYACFG 
#ifdef  DEBUG 

printf("Ready  to  initialize  text  panel\n"); 

#endif  DEBUG 

/*  Define  a  font  for  the  text  subwindow  and  control  panel  */ 

if  (FONT  ==  1){ 
controlfont  = 

pf_open(7usr/lib/fonts/fixedwidthfonts/  screen .  r.  1 6") ; 

} 

else  { 

controlfont  = 

pf_open("/usr/lib/fonts/fixedwidthfonts/screen.r.  11"); 

} 

/*  this  is  a  text  subwindow  *1 

text_sw  =  window_create(base_frame,  TEXTSW, 

WINRIGHTOF ,  acfg_canvas, 

WIN  HEIGHT,  TEXTWINHEIGHT, 

WIN  WIDTH,  TEXTWINWIDTH, 

/*  word  wrap  vice  default  */ 

TEXTSW  LINE_BREAK_ACTION,  TEXTS W  WRAP  AT  WORD , 

0); 

#ifdef  DEBUG 

printf("Ready  to  initialize  comm  panel\n"); 

#endif  DEBUG 

/*  this  is  a  tty  subwindow  */ 

tty_sw  =  window  create(base_frame,  TTY, 

WIN_BELOW,  text_sw, 

WIN  RIGHT  OF,  acfg  canvas, 

WIN~HEIGHT,  TTYWINHEIGHT, 

WIN  WIDTH,  TTYWINWIDTH, 

0); 
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#ifdef  DEBUG 

printf("Ready  to  initialize  control  panel\n"); 

#endif  DEBUG 

/*  this  is  a  panel  subwindow  */ 

control_panel  =  window_create(base_frame,  PANEL, 

WIN  BELOW,  acfg  canvas, 

WIN" HEIGHT,  PANELWINHEIGHT, 
win” WIDTH,  PANELWINWIDTH, 

WIN~X,  0, 

PANEL  ITEM  X  GAP ,  PANELXGAP, 

WIN  FONT,  controlfont, 

0); 

jWfdef  DEBUG 

printf("Ready  to  initialize  control  panel\n"); 

#endif  DEBUG 

/*  puts  file  in  the  text_window  *1 
window_set(text_sw,  TEXTSW  FILE,  filejiame,  0); 

#ifdef  DEBUG 

printf(HReady  to  initialize  button  menu  and  input\nH); 

#endif  DEBUG 

/*  Walker  buttons  and  input  */ 
walker  menu  =  panel  create  item  (con trol_panel, 
PANEL_CHOICE,  PANEL_CHOICE  STRINGS, 

"Run", 

"Help", 

"Save", 

"Quit", 

0, 

PANEL_DISPLAY_LEVEL,  PANEL_NONE, 

PANEL  LABEL  IMAGE,  &walker__pixrect, 

PANEL  NOTIF  Y_PROC ,  walker_proc, 

0); 

/*  Annotate  Button  */ 
if(FONT  ==  1){ 

bold  =  pf  open("/usr/lib/fonts/fixedwidthfcmts/screen.b.l6"); 

} 

else  ( 

bold  =  pf_open("/usr/lib/fonts/fixedwidthfonts/screen.r.ll"); 

} 
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panel  create_item(control_panel,  PANEL  BUTTON, 
PANELNOTIF  Y_PROC ,  call_annotate, 
PANEL_LABEL_IMAGE ,  panel_button_image( 
control_panel,  "Annotate",  9,  bold), 

0); 

/*  Change  Condition  Button  *1 

panel  create  item(control_panel ,  PANEL  BUTTON, 
PANEL  NOTIF Y_PROC ,  call_change, 

P ANEL_L ABEL_IM AG E ,  panel_button_image( 
control jpanel,  "Condition",  9,  bold), 

0); 

/*  Join  Button  */ 

panel_create_item(control_panel,  PANEL  BUTTON, 
P  ANELNOTIF  Y JPROC ,  calljoin,  “ 
PANELLABELIMAGE,  panel_button_image( 
control_panel,  "Join",  8,  bold), 

0); 

/*  Goto  Button  */ 

panel_create_item(control_panel,  PANEL  BUTTON, 
PANEL  NOTIF Y  PROC ,  call^goto, 

PANEL  LABEL  IMAGE,  panel_buttonJmage( 
control_panel,  "Goto",  8,  bold), 

0); 

/*  Prior  Button  */ 

panel_create_item(control_panel,  PANEL  BUTTON, 
PANEL  NOTTFY  PROC ,  caU_prior," 

PANEL  LABEL  IMAGE,  panel_button_image( 
control_panel,  "Prior",  8,  bold), 

0); 

/*  Left  Button  */ 

panel  create_item(control_panel,  PANEL  BUTTON, 
PANEL  NOTIF Y_PROC ,  calljeft, 

PANEL  LABEL  IMAGE,  panel_button_image( 
controljjanel,  "Left",  8,  bold), 

0); 

/*  Right  Button  */ 

panel_create_item(control_panel,  P ANEL  BUTTON , 
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PANELNOTIF  YPROC ,  call_right, 

P ANEL_L ABEL_IMAGE ,  panel_button_image( 
control_panel,  "Right",  8,  bold), 


/*  Node  Button  */ 

panel_create_item(control_panel ,  PANEL  BUTTON, 
PANELNOTIF  YPROC ,  calljiode," 

P ANEL_L ABEL_IM AG E ,  panel_button_image( 
control_panel,  "Node",  8,  bold), 

0); 

/*  Type  Button  */ 

panel_create_item(control_panel,  PANEL_BUTTON, 
PANELNOTIF  YPROC ,  call_type, 
PANELLABELIMAGE,  panel_button_image( 
control_panel,  "Type",  8,  bold), 

0); 

/*  Lister  Button  */ 

panel_create_item(control_panel,  PANELJBUTTON, 
PANELNOTIF  YPROC ,  lister_proc, 

PANEL  LABEL  IMAGE,  panel_button_image( 
control_panel,  "Lister",  8,  bold), 
PANELITEMX,  100, 

PANEL  ITEM  Y,  70, 


/*  This  is  the  input  string  code  for  walker  */ 
walker_input_string  =  panel_create_item( 
control_panel,  PANEL_TEXT, 
PANEL_LABEL_STRING ,  "Walker  input  string:", 
PANEL  VALUE  DISPLA Y_LENGTH ,  50, 
PANEL  ITEM  X,  94, 

P ANEL_ITEM_Y ,  40, 


/*  This  is  the  input  string  code  for  lister  */ 
lister_input_string  =  panel_create_item( 
control_panel,  PANEL_TEXT, 

PANEL  LABEL  STRING,  "Lister  input:", 
PANEL~VALUE~DISPLAY  LENGTH,  15, 
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/*  This  is  the  output  filename  string  code  for  lister  */ 
lister_output_string  =  panel_create_item( 
control_panel,  PANEL_TEXT, 

PANEL_LABEL  STRING,  "Lister  output:", 
panel_value~display_length,  15, 

0); 


#ifdef  DEBUG 

printf("All  buttons  initialized\n"); 

#endif  DEBUG 

window_fit(base_frame) ; 

#ifdef  DEBUG 

printf("Begin  window  main  loop\n"); 

#endif  DEBUG 

window_main_loop(base_frame) ; 
exit(0); 

} 

static  void 
call_annotate() 

{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "a  %s\n", 
panel_get_value(walker_input_string)); 
if  (walker  run  =  =  1)  { 

ttysw_input(tty_sw,  walker  string  buffer,  strlen( 
walkerstringbuffer)) ; 

} 

panel_set_value(walker_input_string,  ""); 

} 

static  void 
call_changeO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "c  %s\n", 
panel_get_value(walker_input_string)); 
if  (walker_run  =  =  1)  { 

ttysw_input(tty_sw,  walker_string_buffer,  strlen( 
walker_string_buffer)) ; 
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} 


} 

panel_set_value(walker_input_string , 


static  void 
callJoinO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "j  %s\n", 
panel_get_value(walker_input_string)); 
if  (walkerrun  =  =  1)  { 

ttysw_input(tty_sw,  walker_string_buffer,  strlen( 
walker_string_buffer)) ; 

} 

panel_set_value(walker_input_string,  " "); 

} 

static  void 
call_goto() 

{char  walker_in_value[81]; 

char  walker_string_buffer[81]; 

strcpy(walker_in_value,  panel_get_value(walker_input_string)) ; 
sprintf(walker_string_buffer,  "g  %s\n",walker_in_value); 
curblock = fmdahbk(walkerinvalue) ; 
ir  ((walker  run  =  =  1)  &&  (curblock!  =  NULL))  { 
ttysw_input(tty_sw,  walker_string_buffer,  strlen( 
walkerstringbuffer)) ; 

} 

else  {  curblock  =  *(ahprocs+ahlen-l); 

/*  eventually,  we’ll  put  a  pop-up  error  message  here  *1 

} 

drawgraph(curblock-  >  abkgrph); 
panel_set_value(walker_input_string ,  ""); 

} 

static  void 
call_priorO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "p\n", 

panel^e^valueCwalke^inpu^string)) ; 
if  (walker_run  =  =  1)  { 

ttysw_input(tty_sw,  walker_string_buffer,  strlen( 


155 


walker_string_buffer)) ; 


} 

panel_set_value(walker_input_string,  " 

} 

static  void 
callleftO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "l\n", 

panel_get_value(walker_input_string)) ; 
if  (walkerrun  =  =  1)  { 

tty sw_input(tty_sw ,  walker_string_buffer,  strlen( 
walkerstringbuffer)) ; 

} 

panel_set_value(walker_input_string ,  " M); 

} 

static  void 
call  rightO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  Mr\n", 

panel_get_value(walker_input_string)); 
if  (walker  run  =  =  1)  { 

ttysw_input(tty_sw,  walkerstringbuffer,  strlen( 
walkerstringbuffer)) ; 

} 

panel_set_value(walker_input_string,  " "); 

} 

static  void 
callnodeO 
{ 

char  walker_string_buffer[813; 
sprintf(walker_string_buffer,  "n  %s\n", 
panel_get_value(walker_input_string)) ; 
if  (walker_run==  1)  { 

ttysw_input(tty_sw,  walker_string_buffer,  strlen( 
walker_string_buffer)) ; 

} 

panel_set_value(walker_input  string,  ""); 

} 
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static  void 
call  typeO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "t  %s\n", 
panel j>et_value(walker_input_string)) ; 
if  (walker_run  =  =  1)  { 

tty sw_input(tty_sw ,  walker_string_buffer,  strlen( 
walker_string_buffer)) ; 

} 

panel_set_value(walker_input_string,  ""); 

} 

static  void 

walker jproc(item,  value,  event) 

Panel  item  item; 
int  value; 

Event  ’“event; 

{ 

char  walker_string_buffer[8 1  ] ; 
if(event_action(event)  =  = 

MS  RIGHT  &&  event_is_down(event))  { 
switch(value)  { 

case  0: 

sprintf(walker_string_buffer,  "walker  -r  reacher_out\n", 
panel jjetvalueCwalkerJnput-String)) ; 
if  (walker  run  =  =  0)  { 

tty sw_input(tty_sw ,  walker_string_buffer , 
strlen( 

walker_string_buffer)) ; 
walker_run  =  1; 

} 

panel_set_value(walker_input_string,  " "); 
break; 

case  1: 

sprintf(walker_string_buffer,  "h\n", 
panel  _get_value(walker_input_string)); 
if  (walker_run  =  —  1)  { 

ttysw_input(tty_sw,  walker_string_buffer, 
strlen(walker_string_buffer)) ; 

} 
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panel_set_value(walker_input_string , 
break; 

case  2: 

sprintf(walker_string_buffer,  "s  %s\n", 
panel_get_value(walker_input_string)); 
if  (walker_run  =  =  1)  { 

tty  s w_input(tty_sw ,  walker_string_buffer, 
strlen(walker_string  buffer)); 

} 

panel_set_value(walker_input_string ,  ""); 
break; 

case  3: 

sprintf(walker_string_buffer,  "q\nH, 

panel^get_value(walker_input_string)) ; 
if  (walkerrun  =  =  1)  { 

ttysw_input(tty_sw ,  walker_string_buffer , 
strlen(walker_string_buffer)) ; 
walkerrun  =  0; 

panel_set_value(walker_input_string,  " "); 
sprintf(walker_string_buffer,  "clear\n", 
panel_get_value(walker_input_string)) ; 
ttysw_input(tty_sw,  walker_string_buffer,  strlenf 
walkerstringbuffer)) ; 

} 

break; 

} 

} 

} 

static  void 
lister_procO 
{ 

char  walker_string_buffer[81]; 
sprintf(walker_string_buffer,  "lister  -o  %s  %s\n", 
panel^get_value(lister_output_string) , 
panel_get_value(lister_input_string)) ; 
ttysw_input(tty_sw,  walker_string_buffer,  strlen( 
walker_string_buffer)) ; 
panel_set_value(lister_input_string,  " "); 
panel_set_value(lister  output_string,  ""); 

} 
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#ifdef  ACFGGRAPH 
static  void 

drawline(curx ,  cury ,  finalx ,  finaly ) 
int  curx,  cury,  finalx, finaly; 

{ 

#ifdef  DEBUG 

printf("Begin  Drawline  Function\n"); 

printf("%d  %d  %d  %d\n",  curx,  cury,  finalx,  finaly); 

#endif  DEBUG 

pw_vector(pw,  curx,  cury,  finalx,  finaly,  PIX_SRC,  1); 

#ifdef  DEBUG 

printf(MLeaving  drawline  function\n"); 

#endif  DEBUG 

} 

static  void 

drawcircle(curx,  cury) 
int  curx; 
int  cury; 

{ 

static  int  npts[l]=  {NUM  POINTS}; 

#ifdef  DEBUG 

printf("Begin  drawing  CircleNn"); 

#endif  DEBUG 

pw_polygon_2(pw,  curx,  cury,  1,  npts,  vlistO,  PIX_CLR,  NULLPR,  0, 

0); 

for(i  =  0;  i < (NUM_POENTS  -  1);  i++)  { 

pw_vector(pw,  vlist0[i].x  4-  curx,  vlist0[i].y  +  cury, 
vlistO[i+l].x  +  curx,  vlistO[i+l].y  +  cury,  PIX  SRC,  1); 

} 

fifdef  DEBUG 

printf("Leaving  circle  function\n"); 

^endif  DEBUG 

} 

#endif  ACFGGRAPH 
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/*  walker. h  -  shared  global  types/defines  for  walker  */ 
/*  T.  Shimeall  July  1990  */ 

/♦guard  against  multiple  expansions*/ 
jWfndef  WALKER 


z/ifndef  EXTERN 

#ifdef  MAIN 

^define  EXTERN 

^define  INIT(Value)  =  Value 

#else 

#define  EXTERN  extern 

^define  INIT(Value) 

//endif  MAIN 
//endif  EXTERN 


//define  NO  STMT 
//define  ASSIGN  STMT 
#define  CALL  STMT 
//define  IF  STMT 
//define  LOOP_STMT 
//define  CASE  STMT 
//define  WITH  STMT 
//define  BEGIN  END 
//define  GOTO  STMT 
//define  OTHER  STMT 
/*  below  here  -  extentions 
/*  R.  Griffin  */ 

//define  EMPTY  STMT 
//define  FCALL  STMT 
//define  IFELSE  STMT 
//define  FLOOP_STMT 
//define  RLOOP  STMT 
//define  CASEIF  STMT 
//define  CASEEXIT_STMT 
//define  UNTIL  STMT 

//define  MAX  NAME 
//define  MAX  COND 
//define  BUFLEN 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

REACHER  tech  report  by  */ 

10 
11 
12 

13 

14 

15 

16 
17 

40 

512 

1024 


typedef  char  condition[MAX_COND]; 
typedef  struct  grphrec  { 
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int  acfgnum; 
int  acfglnum; 
short  marked; 
struct  grphrec  *acfglft; 
struct  grphrec  *acfgrt; 
condition  acfglcnd; 
condition  acfgrcnd; 
int  acfgncalls; 
struct  ahbkrec  **acfgcalls; 
char  acfgtext[BUFLEN]; 
char  acfgsumm[BUFLEN] ; 
int  acfgtype; 

}  acfg; 

typedef  struct  ahbkrec  { 

char  abkname[MAX_NAME] ; 

int  abknumret; 

int  abkcurret; 

acfg  **abkret; 

condition  abkreach; 

acfg  *abkgrph; 

int  abknsubs; 

struct  ahbkrec  **abksubs; 

char  *abkdecl; 

}  ahbkhdr; 

typedef  ahbkhdr  *ahbkref; 

EXTERN  char  ahprgm[MAX_NAME]  INIT("  "); 

EXTERN  int  ahlen  INTT(0); 

EXTERN  ahbkhdr  **ahprocs  INIT(0); 

EXTERN  char  flterr[MAX_NAME]  INIT("  "); 

char  *malloc(); 
char  *reallocO; 

^define  P2CP(Obj)  ((char  *)  Obj) 

^define  INT(Obj)  ((int)  Obj) 

^define  MAKEPOS(Size)  ((INT(Size)>0)  ?  INT(Size) :  1) 

^define  MYALLOC(Size)  malloc(MAKEPOS(Size)) 

^define  MYREALLOC(Obj  ,Size)  ((P2CP(Obj)=  =P2CP(NULL))  ?  MYALLOC(Size)\ 

:  reall oc (Obj, MAKEPOS (Size))) 

#define  MYFREE(Obj)  (P2CP(Obj)  =  =  P2CP(NULL)  ?  NULL  :  free(Obj)) 

^define  WALKER 
tfendif  WALKER 
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/*  ablock.h  —  extern  declarations  for  block  header  */ 
/*  manipulations  */ 

/*  T.  Shimeall  July  1990  */ 


#ifndef  ABLOCK 

extern  void  initahbkO;  /*  initialize  block  */ 

extern  ahbkref  allocahbkO;  /*  allocate  new  block  */ 

extern  void  remahbkO;  /*  delete  named  block  */ 

extern  int  readreacherO;  /*  read  data  from  readier*/ 

extern  void  writereacherO;  /*  write  falter  save  file*/ 

extern  ahbkref  findahbkO;  /*  find  named  block  */ 

extern  ahbkref  findgrphO;  /*  find  block  containing  indicated  node  */ 

#endif 
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/*  acfg.h  -  external  declarations  of  public  functions  in  acfg.c  */ 
/*  T.  Shimeall  October  1989  */ 
jfifhdef  ACFG 


extern  acfg  *findacfgO; 
extern  acfg  *allocacfgO; 
extern  acfg  *findnode(); 
extern  void  cleamodeO; 
extern  void  freeacfgO; 
#endif 


/*  find  or  allocate  acfg  node  */ 

/*  allocate  new  acfg  node  */ 

/*  find  acfg  node  in  graph  */ 

/*  remove  marking  after  acfg  graph  traversal  */ 
/*  add  acfgnode  to  free  list  */ 
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/*  ablock.c  -  block  header  manipulation  routines  */ 
/*  T.  Shimeall  July  1990  */ 

^include  <stdio.h> 

#undef  MAIN 
^define  ABLOCK 
^include  "walker,  h" 

^include  "ablock.h" 

#include  "acfg.h" 


typedef  struct  ahbkkprec  { 

ahbkref  cur;  /*  cur  points  to  a  block  of  10  header  records  */ 
struct  ahbkkprec  '•'next; 
struct  ahbkkprec  *last; 

}  ahbkeep; 

static  ahbkeep  *bkalloc  =  NULL;  /*  allocated  header  blocks  (includes  free)  */ 

static  ahbkeep  *bkcur  =  NULL;  /*  last  entry  of  header  blocks  list  */ 

static  ahbkref  bkfree  =  NULL;  /*  free  header  blocks  */ 

static  char  *bkname  =  NULL;  /*  name  of  next  block,  found  while  reading  */ 

/*  acfg  nodes  */ 

static  int  exitid  =  999999;  /*  initial  id  for  single-exit  nodes  */ 

void  initahbk(hdr)  /*  initialize  header  values  to  zero  values  */ 

ahbkref  hdr; 

{  inti; 

for  (i=0;  i < MAX  NAME;  i++) 
hdr-  >  abkname[i]  =  ’\0’; 
hdr-  >  abknumret  =  0; 
hdr->abkcurret  =  0; 
hdr->abkret  =  (acfg  **)  0; 

strcpy(hdr->abkreach,  "true");  /*  default:  routine  always  gets  called  */ 

hdr->abkgrph  =  (acfg  *)  0; 

hdr- >  abknsubs  =  0; 

hdr->abksubs  =  (ahbkhdr  **)  0; 

hdr->abkdecl  =  (char  *)  0; 

} 

ahbkeep  *allocahkeep0  /*  allocate  entry  of  bkalloc  */ 

{  ahbkeep  *ahbcur; 
ahbkref  cur; 

ahbcur  =  (ahbkeep  *)  MYALLOC(sizeof(ahbkeep)); 
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ahbcur->next  =  NULL; 
ahbcur->last  =  NULL; 

ahbcur->cur  =  (ahbkhdr  *)  MYALLOC(10*sizeof(ahbkhdr)); 
for  (cur  =  ahbcur->cur  ;  cur  <  (ahbcur->cur  +  10);  cur++){ 
initahbk(cur); 

cur->abksubs  =  (ahbkhdr  *♦)  (cur+1); 

} 

(ahbcur->cur+9)->abksubs  =  NULL; 
bkfree  =  ahbcur->cur; 
return  ahbcur; 


ahbkref  allocahbkO  /*  allocate  new  header  block,  using  free  list  */ 

{  ahbkref  cur; 

if  (bkalloc  ==  NULL)  { 
bkalloc  =  allocahkeepO; 
bkcur  =  bkalloc; 

} 

if  (bkfree  ==  NULL)  { 

bkcur- >  next  =  allocahkeepO; 

(bkcur- >  next)- >  last  =  bkcur; 
bkcur  =  bkcur- >  next; 

} 

if  (bkcur  ==  NULL)  { 

printf("Major  problem:  bkcur  null  —  trying  to  recover\n"); 
bkcur  =  bkalloc; 

} 

cur  =  bkfree; 

bkfree  =  (ahbkhdr  *)  bkfree- >abksubs; 
cur->abksubs  =  (ahbkhdr  **)  0; 
return  cur; 


ahbkref  findahbk(name)  /*  find  named  block  */ 

char  ♦name; 

{  ahbkeep  *kp; 
ahbkref  cur; 

if  (name  =  =  NULL)  return  NULL; 
fifdef  DEBUG 

if  (bkcur  =  =  NULL)  printf("Null  block  list\n"); 

#endif 
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kp  =  bkcur;  /*  search  back  to  front  (closer  to  Pascal  scoping  rules)  */ 

while  (kp  !=  NULL)  { 

for  (cur  =  kp->cur;  cur  <  (kp->cur+10);  cur++) 

#ifdef  DEBUG 

{ 

printf("find:  looking  for  %s  checking  % s\n"  .name, cur- > abkname); 
if  (!strcmp(cur->  abkname,  name))  return  cur; 

} 

#else 

if  (!strcmp(cur->  abkname, name))  return  cur; 
tfendif 

kp  =  kp-  >  last; 

} 

return  NULL; 

} 

ahbkref  findgrph(nodeid,cur) 

/*  find  block  containing  node  with  acfgnum=  =nodeid  */ 
int  nodeid;  /*  node  searched  for  */ 

ahbkref  cur;  /*  current  search  location  */ 

{  int  i; 

ahbkref  temp  =  NULL; 
if  (nodeid  =  =  -1)  return  NULL; 
if  (cur  =  =  NULL)  return  NULL; 
if  (findnode(nodeid,cur->  abkgrph)  !=  NULL)  { 
cleamode(cur-  >  abkgrph); 
return  cur; 

} 

for  (i=0;  (i  <  cur-  >  abknsubs)  &&  ((temp  =  findgrph(nodeid,  cur- >  abksubs[i])) 
NULL);  i++)  ; 

cleamode(cur-> abkgrph);  /*  clean  up  after  search  */ 

return  temp;  /*  set  by  for  loop  either  to  NULL  or  to  appropriate  block  *1 
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void  remahbk(cur)  /*  deallocate  header  block,  putting  it  on  the  free  list  */ 

ahbkref  *cur;  /*  double  indirection  so  we  can  set  it  to  null  */ 

{  if  (cur  =  =  NULL)  return;  /*  bad  reference*/ 

if  ((*cur)  =  =  NULL)  return;  /*  nothing  to  deallocate  */ 
initahbk(*cur); 

(*cur)->abksubs  =  (ahbkhdr  **)  bkfree; 
bkfree  =  (*cur); 

(*cur)  =  NULL; 

} 

int  grabint(f,inbuf) 

FILE  *f; 
char  *inbuf; 

{  int  temp; 
temp=-l; 

fgets(inbuf,255,f);  inbuf[strlen(inbuf)-l]  =  *\0’; 
if  (sscanf(inbuf,"%d",&temp)  !=  1  )  temp  =  -1; 
return  temp; 

} 


void  grabstr(f,s,n,inbuf) 

FILE  *f; 

char  *s; 

int  n; 

char  *inbuf; 

{  fgets(inbuf, 255,0;  inbuf[strlen(inbuO-l]  =  ’\0’; 

stmcpy(s,inbuf,n); 

} 
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int  numexit(root) 
acfg  *root; 

{  int  excnt; 

if  (root==NULL)  return  1; 
if  (root-  >  marked)  return  0; 
root- >  marked  =  1; 

if  (root-  >  acfglft  ==  NULL  &&  root-  >  acfgrt  ==  NULL)  return  1 
excnt  —  0; 

if  (root- >  acfglft !  =  NULL) 
excnt  —  numexit(root->  acfglft); 
if  (root- >  acfgrt  !=  NULL) 
excnt  +  =  numexit(root-  >  acfgrt); 
return  excnt; 

} 

void  makeexit(node) 
acfg  *node; 

{ 

node->acfgnum  =  exitid;  exitid— ; 
node->acfglnum  =  1; 
strcpy(node-  >  acfgtext,  " "); 

strcpy(node- >  acfgsumm, "WALKER  added  exit  node"); 

strcpy(node-  >  acfglcnd,  "false"); 

strcpy(node-  >  acfgrcnd.  "false"); 

node- >  acfglft  =  NULL; 

node- >  acfgrt  =  NULL; 

node->acfgncalls  =  0; 

node- >  acfgcalls  =  0; 

node- >  marked  =  1; 

node- >  acfgtype  =  EMPTY_STMT: 

} 
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void  setexit(root, exnode) 
acfg  *root; 

acfg  ♦exnode; 

{  if  (root=  =NULL  j  |  exnode  =  =  NULL)  return; 
if  (root- >  marked  =  =  0)  return; 
root-  >  marked  =  0; 

if  (root-  >  acfglft  ==  NULL  &&  root-  >  acfgrt  ==  NULL  &&  root  !=  exnode) 
root->acfglft  =  exnode; 
else  { 

setexit(root-  >  acfglft, exnode); 
setexit(root-  >  acfgrt, exnode); 

} 


void  singleexit(root) 
acfg  ♦♦root; 

{  acfg  ♦exnode; 

if  (numexit(*root)  >  1)  { 
exnode = allocacfgO ; 
makeexit(exnode) ; 
setexit(*root, exnode); 

} 

c!eamode(*root); 


#ifdef  DEBUG 


^define  ENDTEST(Fileref,Msg)  if  (feof(Fileref)){printf(Msg);  return  -1;}\ 

else  strcpy(flterr,"") 


#else 

^define  ENDTEST(Fileref,Msg)  if  (feof(Fileref)){strcpy(flterr,Msg);  return  -1;}\ 

else  strcpyfflterr,’'") 


#endif 


int  readacfg(f,hdptr) 

FILE  *f; 
acfg  **hdptr; 

{  int  tmpindx; 
acfg  ♦node; 
char  inbuft256]; 
bkname=NULL; 

do  {  tmpindx  =  grabint(f,inbuf); 
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#ifdef  DEBUG 

printf("Read  Ncxie  %d\n",  tmpindx); 

#endif 

if  (tmpindx  =  =  -1)  { 

/*  we’ve  found  the  start  of  the  next  block  */ 

bkname  =  MY  ALLOC  (strlen(inbuf) + 3) ,  /*  3  for  insurance  against  */ 

/*  overflow  */ 

strcpy(bkname,inbuf) ; 

} 

else  { 

if  ((( (int)  *hdptr)  =  =  0)  &&  !feof(0)  { 

*hdptr  =  findacfg(tmpindx); 
node  =  *hdptr; 

} 

else  node  =  findacfg(impindx); 
if  (node  =  =  NULL)  return  0; 

ENDTEST(f,HEnd  of  file  when  expecting  line  number"); 
node- >  acfglnum  =  grabint(f.inbuf); 

ENDTEST(f,"End  of  file  when  expecting  lptr");  tmpindx  = 

grabint(f,inbuf); 

if  (tmpindx  ==  -1)  node-  >  acfglft  =  NULL; 
else  node- >  acfglft  =  findacfg(tmpindx); 

ENDTEST(f,"End  of  file  when  expecting  rptr");  tmpindx  = 

grabint(f,inbuf); 

if  (tmpindx  ==  -1)  node->acfgrt  =  NULL; 
else  node->acfgrt  =  findacfg(tmpindx); 

ENDTEST(f,"End  of  file  when  expecting  lend"); 
grabstr(f,node-  >  acfglcnd,MAX_COND,inbuf); 

ENDTEST(f,"End  of  file  when  expecting  rend"); 
grabstr(f,node-  >  acfgrcnd,MAX_COND,inbuf); 

ENDTEST(f,"End  of  file  when  expecting  ncalls"); 
node->acfgncalls  =  grabint(f,inbuf); 
if  (node-  >  acfgncalls  >0)  { 

node-  >  acfgcalls  =  (struct  ahbkrec  **) 

MYALLOC(node->  acfgncalls  *  sizeof(ahbkref)); 
for  (tmpindx  =  0;  tmpindx  <  node-  >  acfgncalls;  tmpindx ++)  { 
ahbkref  tmp; 

ENDTEST(f,"End  of  file  when  expecting  call  name"); 

grabstr(f,inbuf,MAX_NAME,inbuf); 

tmp  =  node- >  acfgcalls[tmpindx]  =  findahbk(inbuf); 

if  (tmp  =  =  NULL) 
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#ifdef  DEBUG 


{printf(Hcan’t  find  routine  %s\n",inbuf);  return  1; 


#else 


#endif 


} 

{strcpy(flterr, "can’t  find  routine");  return  1; 

} 


/ *  above  line  shouldn’t  happen  */ 

/*  allocate  temporary  storage  for  return  pointers  --  be  generous  *1 
/*  —  reduce  to  actual  later  */ 

if  (tmp-  >  abkret  =  =  NT  ILL) 

tmp->abkret  =  (acfg  **)  MYALLOC(50*sizeof(acfg  *)); 
if  ((tmp->abkcurret  %  50  ==  0)  &&  (tmp->abkcurret>0)) 
tmp-  >  abkret  =  (acfg  **) 

MYREALLOC(tmp-  >  abkret,  (50+ tmp-  >  abkcurret)*sizeof(acfg 

*)); 

tmp->abkret[tmp->abkcurret++]  =  node; 

} 

} 

else  node-  >  acfgcalls  =  NULL; 

ENDTEST(f,  "End  of  file  when  expecting  text"); 
fgets(inbuf,255,f); 
inbuftstrlen(inbuf)-l] =’\0’ ; 
strcpy(node-  >  acfgtext,  inbuf); 

ENDTEST(f,"End  of  file  when  expecting  summary"); 
fgets(inbuf,255,f); 
inbuf[strlen(inbuf)- 1]  —  ’\0’; 
strcpy(node->acfgsumm,  inbuf); 

ENDTEST(f,"End  of  file  when  expecting  node  type"); 
node- >  acfgtype  =  grabint(f,inbuO; 

m  fdef  DEBUG 

printf("@(%d)’%s’\nL:  %d  R:  %d\n", node-  >acfglnum, node- > acfgtext, 
((node- >acfglft==  NULL)  ?  -1  :  node->acfglft->acfgnum), 

((node- >acfgrt==  NULL)  ?  -1  :  node->acfgrt->acfgnum)); 

#endif 

} 

}  while  ((!feof(f))  &&  (bkname  ==  NULL)); 

singleexit(hdptr); 

return  0; 
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int  readfixed(f.hdr) 

FILE  *f; 
ahbkref  hdr; 

{  int  lenread; 
int  lendecl; 
int  readindx; 
int  tmpindx; 
char  inbuf[256]; 

if  (bkname  ==  NULL)  grabstr(f,  hdr- >  abkname,  MAX_NAME,inbuf); 
else  { 

strcpy(hdr- > abkname,  bkname); 

MYFREE(bkname) ; 
bkname  =  NULL; 

} 

ENDTEST (f , M read  of  name"); 
hdr- >  abknumret  =  grabint(f,inbuf); 

ENDTEST(f, "read  of  return"); 
grabstr(f,hdr-  >  abkreach,MAX_COND,inbuf); 

ENDTEST(f, "read  of  cond"); 
hdr- >  abknsubs  =  grabint(f,inbuf); 

ENDTEST (f , " read  of  nsubs"); 
lendecl  =  grabint(f,inbuf); 

/*  read  in  decl  lines  */ 
lenread  =  0; 
if  (lendecl  >0)  { 

hdr->abkdecl  =  (char  *)  MYALLOC(lendecl*160); 

/"■too  much,  will  trim  later*/ 

for  (readindx=l;  readindx <  =lendecl;  readindx ++)  { 

ENDTEST(f, "read  of  decl  line"); 
fgets(inbuf,255,f); 

for  (tmpindx  =0;  tmpindx  <  strlen(inbuf);  tmpindx ++) 
hdr->abkdecl[lenread++]  =  inbuf[tmpindx]; 

/♦include  \n  at  end  of  line*/ 

if  (lenread  >  (lendecl* 160  -  40))  return  -2;  /*  lines  too  long  */ 

} 

hdr->abkdecl  =  (char  *)MYREALLOC(hdr-  >abkdecl, lenread  +  1); 
/♦trim  storage*/ 

} 

else  hdr->abkdecl  =  (char  *)  MYALLOC(l); 
hdr-  >  abkdecl(lenread + +]  =  ’\0’; 

/*  allocate  return  location  storage  */ 
if  (hdr- >  abknumret  >0)  { 
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if  (hdr->abkret  =  =  NULL)  /*  no  calls  from  parent  */ 

hdr->abkret  =  (acfg  **)  MYALLOC((hdr->abknumret)*sizeof( 
acfg  *)); 

else  I*  trim  space  from  overestimate  parent  uses  to  actual  needs  *7 
hdr-  >  abkret  =  (acfg  **) 

MYREALLOC(hdr-  >  abkret, (hdr-  >  abknumret)*sizeof(acfg  *)); 

/*  abkcurret  is  initialized  to  0  and  incremented  on  each  call  */ 
if  (hdr- >  abkcurret  >  hdr- >  abknumret)  return  4;  /*  too  many  calls  */ 
for  (tmpindx = hdr- > abkcurret;  tmpindx< hdr- > abknumret;  tmpindx++) 
hdr->abkret[tmpindx]  =  NULL; 

} 

else  hdr-  >  abkret  =  NULL; 

I*  allocate  submodule  storage  */ 
if  (hdr->abknsubs  >  0)  { 

hdr->abksubs  =  (ahbkhdr  **)  MYALLOC(hdr-  >  abknsubs  * 
sizeof(ahbkref)); 

for  (tmpindx  =  0  ;  tmpindx  <  hdr-  >  abknsubs;  tmpindx ++) 

*(hdr-  >  abksubs  4-  tmpindx)  —  allocahbkO ; 

} 

/*  read  in  submodule  names  */ 

for  (tmpindx  =  0;  tmpindx  <  hdr- > abknsubs;  tmpindx++){ 
ENDTEST(f,"read  of  sub  name"); 

grabstr(f,(*(hdr-  >  abksubs + tmpindx))-  >  abkname,MAX_NAME,inbuf); 
#ifdef  DEBUG 

printf("Read  in  submodule  ref  of  % s\n " , (*(hdr-  >  abksubs + tmpindx))-  >  abkname) ; 
#endif 

} 

return  0; 
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int  readreacher(f,hdr) 

/*  Read  reacher-generated  file  f  to  get  data  for  block  header  hdr;  */ 

/*  return  -1  if  problem  with  read,  return  0  if  read  is  successful  */ 

FILE  *f;  /*  assumed  to  already  be  opened  */ 

ahbkref  hdr;  I*  assumed  to  already  be  initialized  */ 

{  char  inbuf[80]; 

int  tmpindx; 

#ifdef  DEBUG 
acfg  *node; 

#endif 

if  (f  =  =  NULL)  return  -1;  /*  no  file  to  read  from  */ 
if  (hdr  =  =  NULL)  return  -1;  /*  no  place  to  copy  to  */ 
ENDTEST(f,"test"); 

/*  read  in  fixed  data:  name,  numret,  reach,  nsubs,  number  of  decl  lines;"'/ 
/*  allocate  return  storage  and  submodule  storage;  */ 

I*  read  in  decl  lines  and  subroutine  names  */ 
if  (readfixed(f,hdr)!  =0) 

#ifdef  DEBUG 

{printf("readfixed  ended  abnormally\n"); 

return  3;} 

#else 

return  3; 

#endif 

#ifdef  DEBUG 

printf("Read  block  %s\n",hdr-> abkname) ; 

#endif 

/*  read  in  module  acfg  data  */ 
fifdef  DEBUG 

if  (readacfg(f,&(hdr->abkgrph))!=0)  { 
printf("readacfg  ended  abnormally\n"); 
return  3; 

} 

node=hdr-  >abkgrph; 

printf("readacfg  ended  normally\nStart  of  acfg:\n"); 
printf("#%d  @(%d)’%s’\nL:%d  R:%d\n",node->acfgnum, 
node-  >  acfglnum.node-  >  acfgtext, 

((node-  >  acfglft  =  =  NULL)  ?  -1  :  node->acfglft->acfgnum), 

((node-  >  acfgrt  =  =  NULL)  ?  -1  :  node->acfgrt->acfgnum)); 
node  =  ((node- >  acfglft!  =  NULL)  ?  node-  >  acfglft: 

(node-  >  acfgrt!  =NULL)  ?  node-  >  acfglft:NULL); 
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if  (node!  =NULL) 

printf(",¥%d  @(%d)’%s’\nL:%d  R :  % d\n " , node-  >  acfgnum , 
ncxie-  >  acfglnum,node-  >  acfgtext, 

((node->acfgIft==NULL)  ?  -1  :  node-  >  acfglfi-  >  acfgnum), 
((node->acfgrt==NULL)  ?  -1  :  node- >acfgrt->  acfgnum)); 
#else 

if  (readacfg(f,&(hdr->abkgrph))!=0)  return  3; 
tfendif 

/*  read  in  submodules*/ 
if  (hdr->abknsubs>0) 

for  (tmpindx  =0;  tmpindx  <  hdr->abknsubs;  tmpindx ++)  { 
ENDTEST(f,"test"); 

if  (readreacher(f,  hdr-  >  abksubs[tmpindx])  !  =  0) 
tffdef  DEBUG 

{printf(Mreadreacher  ended  abnormally\n"); 
return  3; 

} 

#else 


return  3; 

#endif 

} 

else  fgets(inbuf,80,f);  /*  comment  line  */ 

return  0;  /*  successfully  read  */ 


#undef  ENDTEST 

static  acfg  *  terminal  =  NULL; 

void  dumpacfginfo(f.root) 

FILE  *f; 
acfg  *root; 

{  int  tmpindx; 

if  (root  =  =  NULL)  return; 

fjprintf(f,"%d\n%d\n",  root- >  acfgnum,  root->acfglnum); 
root- >  marked  =1; 

if  (root-  >  acfglft  ==  NULL)  fputs("-l\n",0; 
else  fprintf(f, "%d\n", root-  > acfglft-  > acfgnum); 
if  (root->acfgrt  ==  NULL)  fputs(*-l\n",f); 
else  fprintf(f , "  %d\n"  .root-  >  acfgrt-  >  acfgnum); 
fputs(root->acfglcnd,f);  fputc(’\n’,f); 

^>uts(root-  > acfgrcnd.f);  fputc(’\n’,f); 
fj)rintf(f, "  %d\n"  .root-  >  acfgncalls); 
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for  (tmpindx=0;  tmpindx  <  root->acfgncalls;  tmpindx++)  { 
fputs(root-  >  acfgcalls[tmpindx]-  >  abkname,f); 
fputc(’\n’,f); 

} 

fputs(root->acfgtext,f);  fputc(’\n’,f); 

fyuts(root- > acfgsumm.f);  fputc(’\n’,f); 
fprintf(f, "  %d\n"  ,root-  >  acfgtype); 


void  writeacfg(f,  root) 

FILE  *f; 
acfg  ♦root; 

{  if  (root  =  =  NULL)  return;  /*  no  data  to  write  */ 

if  (root-  >  marked)  return;  /*  loop  back,  we’ve  already  done  this  node*/ 
if  (root->acfglft  =  =  NULL  &&  root->acfgrt  ==  NULL)  { 
if  (terminal  !  =  NULL  &&  root  !  =  terminal)  { 

fprintf(stderr, "Illegal  graph  in  writeacfg  (two  terminal  nodes)\n"); 
exit(l); 

} 

terminal  =  root;  /*  save  for  output  at  end  */ 
return; 

} 

dumpacfginfo(f,root); 

fflush(f); 

if  (root->acfglft!=NULL)  writeacfg(f,root->acfglft); 
if  (root->acfgrt!=NULL)  writeacfg(f,root->acfgrt); 


void  writereacher(f,  proc) 

FILE  *f; 
ahbkref  proc; 

{  int  tmpctr,  tmpidx; 

fputs(proc- > ad)kname,f);  fputc(’\n’,f); 
fprintf(f,"  %d\n",proc-  >  abknumret); 

^>uts(proc- > abkreach , f) ;  fputc(’\n’,f); 
fi>rintf(f, "  %d\n"  ,proc-  >  abknsubs); 
tmpctr  =  0; 

if  (proc-  >  abkdecl!  =NULL){ 

for  (tmpidx  =0;  tmpidx  <  strlen(proc- > abkdecl);  tmpidx++) 
if  (proc- >  abkdecl[tmpidx]  ==  ’\n’)  tmpctr++; 
fprintf(f, "  %d\n"  .tmpctr); 
fj>rintf(f,  *  %sm  ,proc-  >  abkdecl); 
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for  (tmpidx =0;  tmpidx<proc->abknsubs;  tmpidx++)  { 
fputs(proc-  >  abksubs[tmpidx]-  >  abkname,f); 
fputc(’\n’,f); 

} 

} 

else  fputs("0\n*,f); 
fflush(f); 

terminal  =  NULL;  /*  clear  any  prior  traversal  */ 
writeacfg(f,proc-  >  abkgrph); 
dumpacfginfo(f, terminal);  /*  dump  sink  node  last  */ 
fflush(f); 

cleamode(proc-  >  abkgrph); 

for  (tmpidx =0;  tmpidx  <  proc-  >  abknsubs;  tmpidx  +  +) 
writereacher(f,proc-  >  abksubs[tmpidx]); 

} 
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/*  acfg.c  --  annotated  control-flow  graph  management  functions  for  walker  */ 
/*  T.  Shimeall  July  1990  (from  falter)  */ 

^define  ACFG 
#include  <stdio.h> 

^include  "walker.h" 

typedef  struct  acfgkrec  { 
acfg  *cur; 

struct  acfgkrec  *next; 
struct  acfgkrec  ’‘last; 

}  acfgkeep; 

static  acfgkeep  *ndalloc  =  NULL;  /*  allocated  acfg  nodes  */ 
static  acfgkeep  *ndcur  =  NULL;  /*  last  entry  of  nodes  list  *1 
static  acfg  ’‘acfg free  =  NULL;  /*  free  node  blocks  *1 


acfgkeep  ’‘allocndkeepO  /*  allocate  entry  of  ndalloc  *1 

{ 

acfgkeep  *acgcur; 
acfg  *cur; 

acgcur  =  (acfgkeep  *)  MYALLOC(sizeof(acfgkeep)); 
acgcur-  >  next  =  NULL; 
acgcur- >  last  =  NULL; 

acgcur- >  cur  =  (acfg  *)  MYALLOC(10*'sizeof(acfg)); 
for  (cur  =  acgcur-  >  cur  ;  cur  <  (acgcur- >  cur  +  10);  cur++){ 
cur-  >  acfglft  =  (acfg  *)  (cur+ 1); 

} 

(acgcur-  >cur+9)->  acfglft  =  NULL; 
acfgfree  =  acgcur- >  cur; 
return  acgcur; 

} 


void  freeacfg(node)  I*  put  node  on  free  list  */ 

acfg  **node; 

{ 

(•node)-  >  acfglft  =  acfgfree; 

(’,node)->acfgrt  =  NULL; 
acfgfree  =  ’‘node; 
acfgfree-  >  acfgncalls  =  0; 

•node  =  NULL; 

} 
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acfg  *allocacfgO 


/*  allocate  new  acfg  node,  using  free  list  */ 


{ 

acfg  *cur; 

if  (ndalloc  =  =  NULL)  { 

ndcur  =  ndalloc  =  allocndkeepO; 

} 

if  (acfgfree  =  =  NULL)  { 

ndcur- >  next  =  allocndkeepO; 

(ndcur- >  next)- >  last  =  ndcur; 
ndcur  =  ndcur- >  next; 

} 

cur  =  acfgfree; 

acfgfree  =  (acfg  *)  acfgfree-  >  acfglft; 

cur-  >  acfglft  =  (acfg  *)  0; 

cur- >  marked  =  0; 

return  cur; 

} 

/*  find  (or  create)  acfg  node  with  id  given  parametrically  */ 
acfg  *findacfg(id) 
int  id; 


acfg  *cur; 
acfgkeep  *kp; 


if  (id  ==  -1)  return  NULL; 
if  (ndalloc  !=  NULL)  { 
kp  =  ndalloc; 
while  (kp  !  =  NULL)  { 

for  (cur  =  kp->cur;  cur  <  =  (kp->cur  +  9);  cur++) 
if  (cur->acfgnum  ==  id)  return  cur; 
kp  =  kp->next; 

} 


} 


cur  =  allocacfgO; 
cur->acfgnum  =  id; 
return  cur; 
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acfg  *findnode(nodeid,  root)  /*  find  node  in  graph  */ 
int  nodeid; 
acfg  *root; 

{ 

acfg  *lftret; 

if  (root  =  =  NULL)  return  NULL; 
if  (nodeid  =  =  -1)  return  NULL; 

if  (root-  >  marked)  return  NULL;  /*  already  checked  this  */ 
if  (root->acfgnum  ==  nodeid)  return  root; 
root- >  marked  =  1; 

if  ((lftret  =  findnode(nodeid,  root- >acfglft))!=  NULL)  return  lftret; 
return  findnode(nodeid,root->acfgrt); 

} 

void  cleamode(root)  /*  clear  marking  after  graph  traversal  */ 

acfg  *root; 

{ 

if  (root  =  =  NULL)  return; 
if  (!root->  marked)  return; 
root- >  marked  =  0; 
cleamode(root-  >  acfglft); 
cleamode(root-  >  acfgrt); 

} 
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I*  TITLE 

*  AUTHORS 

*  DATE 

*  REVISED 

*  SYSTEM 

*  LANGUAGE 

*  COMPILER 


:  faltwin.c 

:  Vicki  Abel  and  Medio  Monti 
:  20  October  1990 
:  12  December  1990 
:  NPS  SUN  TAURUS 
:  SunView  and  C 
:  Unix  cc 

*  DESCRIPTION  :  This  program  is  the  interface  for  the  failure  region 

*  testing  tool  FALTER.  It  is  similar  in  design  and  construction  to  the  WALKER 

*  interface  but  functions  to  serve  FALTER 's  needs. 

*/ 


/*  These  are  the  SunView  header  files  needed  for  this  program.  */ 
/define  MAIN  /*  Necessary  for  the  acfg  graph  */ 

/include  <suntool/sunview.h> 

/include  <  suntool/panel.h  > 

/include  <  suntool/textsw.h  > 

/include  <suntool/tty.h> 

/include  <suntool/canvas.h> 

/include  <suntool/icon.h> 

/include  <suntool/scrollbar.h> 

/include  <  pixrect/pr  line.  h  > 

/include  <stdio.h> 

/include  <math.h> 

/*  These  macros  contain  declarations  necessary  for  drawing  the 

*  acfg  graph.  These  header  files  are  from  Dr.  ShimealFs  testing 

*  tools. 

*1 


/ifdef  ACFGGRAPH 
/include  "walker.h" 
/include  "ablock.h" 
/include  "acfg.h" 
/endif  ACFGGRAPH 


/define  NUM  POINTS  1000  1*  for  President  Bush  */ 

/define  XSTART 

200 

/define  YSTART 

100 

/define  XDONE 

200 

/define  YDONE 

200 

/define  POSMAX 

200 
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/*  Presently  necessary  for  defining  a  high  resolution  screen  */ 


#ifdef  HIGHRES 

^define  STARTX  200 

^define  STARTY  50 

^define  RADIUS  10 

#define  BASEFRAMEX  525 

^define  BASEFRAMEY  205 

^define  ACFGHEIGHT  794 

#define  ACFGWIDTH  500 

^define  C ANV ASHEIGHT  1400 

^define  CANVASWIDTH  900 

^define  TEXTWINHEIGHT  394 

^define  TEXTWINWIDTH  495 

^define  TTYWINHEIGHT  394 

^define  TTYWINWIDTH  495 

#define  PANEL W1NHEIGHT  100 

^define  PANELWINWIDTH  1000 

^define  PANELXGAP  10 

^define  FONT  1 

#define  XDISP  25 

^define  YDISP  25 

tfendif  HIGHRES 

#ifdef  LOWRES 

^define  STARTX  150 

^define  STARTY  25 

^define  RADIUS  15 

^define  BASEFRAMEX  365 

^define  BASEFRAMEY  163 

^define  ACFGHEIGHT  476 

^define  ACFGWIDTH  350 

^define  C  ANV  ASHEIGHT  540 

^define  CANVASWIDTH  890 

^define  TEXTWINHEIGHT  236 

^define  TEXTWINWIDTH  347 

^define  TTYWINHEIGHT  236 

^define  TTYWINWIDTH  347 

^define  PANELWINHEIGHT  100 

^define  PANELWINWIDTH  702 

^define  PANELXGAP  5 

^define  FONT  0 

^define  XDISP  15 

#define  YDISP  12 
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#endif  LOWRES 


/*  these  define  pixrect  ptrs  *1 
^define  NULLPR  ((Pixrect  *)  0) 

/*  vlist  is  an  array  of  structures  pr_pos  for  the  circle  */ 
static  struct  pr_pos  vlistO[NUM_POINTS] ; 

/*  type  declarations  *1 
Frame  base_frame; 

Panel  control_panel; 

Canvas  acfg_canvas; 

Textsw  text_sw; 

Tty  ttysw; 

Panelitem  faltermenu, 
falter_string_item; 


Pixfont  "“bold; 

/*pixwin  object  */ 

Pixwin  *pw; 

int  i,  j; 

int  startxval  =  XSTART; 

int  startyval  =  YSTART; 

int  finishxval  =  XDONE; 

int  finishyval  =  YDONE; 

float  angle;  /*  for  circle  computations  */ 

float  increment;  I*  for  circle  computations  */ 

int  counter  =  0;  /*  for  circle  computations  */ 

int  falter  run  =  0; 

/*  name  of  file  to  load  into  text  subwindow  */ 
char  *file_name; 
jWfdef  ACFGGRAPH 

FILE  *infile;  /*  Logical  file  name  for  acfg  graph  */ 
#endif  ACFGGRAPH 

#ifdef  ACFGGRAPH 
/*  Graph  object  declarations  */ 
int  curx; 

int  cury; 

int  finalx; 
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int  finaly; 

int  rootid; 

/*  structure  for  an  (x,y)  coordinate  */ 
typedef  struct 
{ 

int  x; 
int  y; 

}POINT; 

/*  Array  of  the  above  structures  */ 

POINT  position[200]; 
int  TOS  =  0;  /*  Top  of  Stack  */ 

acfg  *cumode;  /*ptr  to  acfg  */ 

ahbkref  curblock;  /*ptr  to  hdr  structure  */ 
acfg  *stack[200];  /*stack  of  acfg  structures  */ 

#endif  ACFGGRAPH 

Icon  falter_icon; 

Icon  falter_menu_icon; 

/*  These  procedures  are  notified  by  the  buttons.  */ 

static  void  call_add(); 

static  void  callannotateO; 

static  void  call_error(); 

static  void  call  error  locO; 

static  void  call^get  errorO; 

static  void  call_implicationO; 

static  void  call  leftO; 

static  void  call^gotoO; 

static  void  call_node0; 

static  void  call_prior(); 

static  void  call_rightO; 

static  void  call  set  valueO  ; 

static  void  call_error_typeO; 

static  void  call_violation_setO; 

#ifdef  ACFGGRAPH 

static  void  drawlineO;  /*  For  drawing  arcs  between  nodes  */ 

static  void  drawcircleO;  /*  For  drawing  the  nodes  */ 

#endif  ACFGGRAPH 

static  void  falter_procO;  /*  process  for  falter  menu  */ 
static  short  icon_imageO  =  { 
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^include  "falter,  icon 

}; 


mpr_static(icon_pixrect,  64,  64,  1,  icon_image); 

static  short  falter_arrayQ  ={ 

^include  "falter  menu.icon" 

}; 


mpr_static(falter_pixrect,  64,  64,  1,  falter  array); 

^define  ADDEDEXIT  NODE  999999 
int  shifts[POSMAX] ; 

void  subtreeshift(root,disp) 
acfg  ♦root; 
int  disp; 

{if  (root  =  =  NULL)  return; 

if  (root->acfgnum  ==  ADDED_EXIT_NODE)  return; 
shifts[root->acfgnum  -  rootid]  +=  disp; 
subtreeshift(root->acfglft,  disp); 
subtreeshift(root-  >  acfgrt, disp); 

} 

int  calcoffsets(root) 
acfg  *root; 

{int  leftval,  rightval; 

if  (root=  =NULL)  return  0; 

if  (root-  >  marked  =  =  1)  return  0;  /*  crossovers  possible  */ 
root- >  marked  =  1; 

if  (root- > acfgnum  =  =  ADDED  EXIT  NODE)  { 
shifts[POSMAX-l]  =0; 

} 

else  { 

shifts[root->  acfgnum  -  rootid]  =  0; 

} 

if  (root->acfglft  ==  NULL)  return  0; 
if  (root-  >  acfgrt  ==  NULL)  return  calcoffsets(root- >  acfglft); 
leftval  =  calcoffsets(root-  >  acfglft); 
rightval  =  calcoffsets(root->  acfgrt); 
if  (leftval  >0) 
if  (rightval  >0)  { 

subtreeshift(root->  acfglft,  -  (leftval + rightval + 1)/2); 
subtreeshift(root-  >  acfgrt,  (leftval + rightval + 1)/2); 
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} 

else  { 

subtreeshift(root->acfgrt,  1  +  leftval/2); 
subtreeshift(root->acfglft,  -(1+ leftval/2)); 

} 

else  { 

subtreeshifi(root->acfglft,  -  (rightval  +  2)/2); 
subtreeshift(root->acfgrt,  (rightval+2)/2); 

} 

return  (int)  1 . 5  *Oeftval + rightval) + 1 ; 

} 

void  drawgraph(root) 
acfg  *root; 

{ int  done  draw  =  0; 
cumode  =  root; 
rootid  =  root->acfgnum; 
curx  =  STARTX; 
cury  =  STARTY; 

calcoffsets(root); 

clearnode(root); 

pw_writebackground(pw,0,0, 

(pw-  >  pw_pixrect)-  >  pr_size.x,(pw-  >  pw_pixrect)-  >  pr_size.y,PIX_CLR); 
do  { 

#ifdef  DEBUG 

printf(M  Drawing  node  %d  (%d)  into  pos  %d\n", cumode- >acfgnum, 
cumode,cumode-  >  acfgnum-rootid) ; 

#endif  DEBUG 

if  (cumode  =  =  NULL)  { 

printf("  ran  off  edge  of  graph\n"); 
break; 

} 

if(cumode->acfgrt !  =  NULL)  { 

#ifdef  DEBUG 

printf("  Pushing  node  %d  (%d)  into  stack  %d\n", cumode- > acfgnum, cumode, TOS); 
#endif  DEBUG 
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stackJTOS]  =  cumode; 

TOS++; 

finalx  =  curx  -  XDISP  + 

((cumode-  >  acfglft-  >  marked  =  =  1)  ?  0  : 

((cumode- >acfglft->acfgnum  ==  ADDED_EXIT_NODE)  ?  0 
shifts[cumode-  >  acfglft-  >  acfgnum-rootid])); 
finaly  =  cury  +  YDISP; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 

if  (cumode-  >  acfgnum  =  =  ADDED_EXIT_NODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX-l].y  =  cury; 

} 

else  { 

position[cumode->  acfgnum-rootid]. x  =  curx; 
positionfcumode- >  acfgnum-rootid].  y  =  cury; 
curx  =  finalx; 
cury  =  finaly; 
cumode- >  marked  =  1; 

#ifdef  DEBUG 

printf("  Advancing  left  to  node  %d\n", cumode- > acfglft); 

#endif 

cumode  =  cumode- >  acfglft; 

} 

} 

else  if(cumode-  >  acfglft  ==  NULL  &&  TOS>0)  { 

#ifdef  DEBUG 

printf("  Popping  node  %d  (%d)  from  stack  %d\n",stack[TOS-l]-> acfgnum, 
stack[TOS-l],TOS-l); 

/jfendif  DEBUG 

TOS— ; 

cumode  =  stackfTOS]; 
finalx  =  curx  +  XDISP  + 

((cumode- >acfgrt->  marked  =  =  1)  ?  0  : 

((cumode-  >  acfgrt-  >  acfgnum  ==  ADDED  EXIT  NODE)  ?  0 
shifts[cumode-  >  acfgrt-  >  acfgnum-rootid])); 
finaly  =  cury  +  YDISP; 

if  (cumode- >  acfgnum  ==  ADDED_EXTT_NODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX- 1  j .  y  =  cury; 
drawcircle(curx,  cury); 

} 
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else  { 

position[cumode->acfgnum-rootid].x  =  curx; 
position[cumode->acfgnum-rootid].y  =  cury; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 
curx  =  finalx; 
cury  =  finaly; 

#ifdef  DEBUG 

printf("  Advancing  right  to  node  %d\n"  .cumode- >acfgrt); 

#endif 

cumode  =  cumode-  >  acfgrt; 

} 

} 

else  if  (cumode- >acfglft  !=  NULL)  { 

if  (cumode- >acfgnum  !=  ADDED_EXIT_NODE)  { 

#ifdef  DEBUG 

printf("  Advancing  down  to  node  %d\n"  .cumode- >acfglft); 

^endif 


cumode  =  cumode-  >  acfglft; 

finalx  =  curx; 

finaly  =  cury  +  YDISP; 

if  (cumode-  >  acfgnum  =  =  ADDED  EXIT  N ODE)  { 
position[POSMAX-l].x  =  curx; 
position[POSMAX-l].y  =  cury; 
drawcircle(curx,  cury); 

} 

else  { 

positior(cumode->acfgnum-rootid].x  =  curx; 
position[cumode->acfgnum-rootid].y  =  cury; 
drawline(curx,  cury,  finalx,  finaly); 
drawcircle(curx,  cury); 
cury  =  finaly; 

} 

} 

else  {done  draw  =  1;} 

} 

if  (cumode!  =NULL) 
while((!done_draw)  && 

((cumode- >  acfgnum  ==  ADDED  EXIT_NODE)  |  j  (cumode-  >  marked 

=  =  1)) 

&&  (TOS  >  0))  { 
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#ifdef  DEBUG 

printf("  Popping  node  %d  (%d)  from  stack  %d\n"  ,stack[TOS-l]-  >  acfgnum, 
stack[TOS-l],TOS-l); 

#endif  DEBUG 

cumode  =  stack[TOS-l]; 

if  (cumode  ==  NULL)  {done_draw = 1 ;  cumode=root;  break;} 
if  (cumode- >  acfgnum  ==  ADDED_EXIT_NODE)  { 
curx  =  position[POSMAX].x; 
cury  =  position[POSMAX].y; 

} 

else  { 

curx  =  position[cumode->acfgnum-rootid].x; 
cury  =  position[cumode->acfgnum-rootid].y; 

} 

if  (cumode- >  acfgrt  ==  NULL)  {done_draw  =  l;  break;} 
finalx  =  curx  +  XDISP  + 

(cumode- >  acfgrt- >  marked  =  =  1)  ?  0  : 

((cumode- >  acfgrt- >  acfgnum  ==  ADDED  EXIT  NODE)  ?  0 
shifts[cumode-  >  acfgrt-  >  acfgnum-rootid])); 
finaly  =  cury  +  YDISP; 
drawline(curx,  cury,  finalx,  finaly); 
curx  =  finalx; 
cury  =  finaly; 
fifdef  DEBUG 

printf("  Advancing  remaining  link  to  node  % d\n", cumode- > acfgrt); 

#endif 

cumode  =  cumode- >  acfgrt; 

TOS— ; 

} 

else  {done  draw  =  1; 
cumode  =  root; 

} 

}  while  (!done_draw  &&  ((cumode-  >  acfglft !  =  NULL)  1 1 
(cumode-  >  acfgrt  !=  NULL)  1 1 
(TOS  >  0))); 

if  (!done_draw)  drawcircle(curx,  cury); 

} 


/* - MAIN  PROGRAM - */ 


main(argc,  argv) 
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int  argc; 
char  *argvO; 

{ 

static  int  npts[l]  =  { NUM_POINTS } ; 

/*  assign  second  item  of  input  line  to  filename  to  display  it  *7 
/*  in  the  text  subwindcw  *1 
file_name  =  argv[l]; 

falter_icon  =  icon_create(ICON_IMAGE,  &icon_pixrect,  0); 

/*  this  is  the  base  frame  for  the  application  */ 
base  frame  --  window_create(NULL,  FRAME, 

WINX,  BASEFRAMEX,  /*  sets  x  position  relative  to  owner  */ 
WIN  Y,  BASEFRAMEY,  /*  sets  y  position  relative  to  owner  */ 
FRAME JLABEL,  "Falter  Window  1.0",  /*  frame  label  *1 
FRAMEJCON,  falterjcon,  /*  icon  used  */ 

FRAME  ARGS,  argc,  argv,  /*  main  args  */ 

0); 

/*  this  is  a  graphics  subwindow  */ 

acfg  canvas  =  winuow_create(base_frame,  CANVAS, 

WIN  HEIGHT,  ACFGHEIGHT, 

WIN  WIDTH,  ACFGWIDTH, 

CANVAS  AUTO  EXPAND,  FALSE, 
CANVASAUTOSHRINK,  FALSE, 

CANVASWIDTH,  CANVAS  WIDTH, 
canvasIheight,  CANVASHEIGHT, 

WIN  VERTICAL  SCROLLBAR,  scrollbar_create( 
SCROLL_PLACEMENT,  SCROLL  WEST, 
SCROLL_PAGE_BUTTONS ,  FALSE, 

0), 

WIN_HORIZONTAL_SCROLLBAR,  scrollbar_create( 
SCROLL_PLACEMENT,  SCROLL  SOUTH, 

SCROLL_P  AGE_BUTTONS ,  FALSE, 

0), 

0); 

#ifdef  ACFGGRAPH 
#ifdef  DEBUG 

printf("Ready  to  start  graph.c\n"); 

#endif  DEBUG 

/* - graph.c  main  code - */ 

/*  reacher_out  is  where  we  find  the  textual  representation  of  the 
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*  control  flow  graph.  We  must  put  it  into  the  logical  file  to  use 

*  use  it. 

*/ 

infile  =  fopen("walker_out",  "r"); 

if  (infile  =  =  NULL)  infile  =  fopen("  readier  out","r"); 

if  (infile  ==  NULL)  { 

fprintf(stderr,"No  walker_out  or  reacher_out  file\n"); 
exit(l); 

} 

ahlen  =  0; 

/♦  Dynamically  allocate  memory  for  the  logical  file  and  put  it  into 

*  memory.  The  function  readreacher  is  part  of  the  failure  region 

*  testing  tools.  We  used  it  with  our  program  with  Dr.  Shimeall’s 

*  permission. 

♦/ 

while(!feof(infile))  { 

i; 

ahlen+  +  ; 
i  =  sizeof(ahbkref); 

if(ahlen  >  1)  { 

ahprocs  =  (ahbkhdr  *  *)M YREALLOC (ahprocs ,  ahlen*i); 

} 

else  { 

ahprocs  =  (ahbkhdr  **)  MYALLOC(i); 

} 


♦(ahprocs  +  ahlen-1)  =  allocahbkO; 
readreacher(infile,  *(ahprocs  +  ahlen-1)); 

} 

fifdef  DEBUG 

printf("Ready  to  draw  graph\n"); 

#endif  DEBUG 
/*  initialize  ♦/ 

curblock  =  *(ahprocs  +  ahlen-1); 
cumode  =  curblock- >abkgrph; 

if  (cumode  =  =  NULL)  { 

fprintf(stderr,"No  nodes  in  walker_out  main  block\n"); 
exit(l); 
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} 


/*  Define  pw  and  set  up  circle  coordinates  */ 
pw  =  canvas_pixwin(acfg  canvas); 
increment  =  2  *  M_PI  /  NUM_POINTS; 
for(angle  =  0;  angle  <  (2  *  nT_PI);  angle  +  =  increment)  { 
vlistO[counter].x  =  RADIUS  *  cos(angle); 
vlistO[counter].y  =  RADIUS  *  sin(angle); 
counter++; 

} 

drawgraph(curblock-  >  abkgrph); 

#ifdef  DEBUG 

printf("Ready  to  initialize  graphics  panel\n"); 
tfendif  DEBUG 

#endif  ACFGGRAPH 


/*  this  is  a  text  subwindow  */ 

text  sw  =  window_create(base_frame,  TEXTS W, 

WINRIGHTOF,  acfgcanvas, 

WINHEIGHT,  TEXTWINHEIGHT, 

WIN  WIDTH,  TEXTWINWIDTH , 

/*  word  wrap  vice  default  */ 

TEXTSW  LINE  BREAK  ACTION,  TEXTS W  WRAP  AT  WORD , 

0); 

/*  this  is  a  tty  subwindow  */ 

tty_sw  =  window_create(base_frame,  TTY, 

WIN_BELOW,  text_sw, 

WIN  RIGHT  OF ,  acfg_canvas, 

WIN  HEIGHT,  TTYWINHEIGHT, 

WIN  WIDTH,  TTYWINWIDTH, 

0); 

/*  this  is  a  button  subwindow  */ 

coritrol_panel  =  window_create(base_frame,  PANEL, 

WIN  BELOW,  acfg_canvas, 

WIN_HEIGHT,  PANELWINHEIGHT, 

WIN  WIDTH,  PANELWINWIDTH, 

WINX,  0, 

PANEL_ITEM  X  GAP,  PANELXGAP, 
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0); 


/*  puts  file  in  the  text_window  */ 

window_set(text_sw,  TEXTSW_FELE,  file_name,  0); 


/*  Falter  buttons  and  input  */ 

falter  menu  =  panel_create  item(control_panel, 
PANELCHOICE,  PANEL_CHOICE  STRINGS, 
"Run", 

"Help", 

"Save", 

"Quit", 

0, 

P  ANELDISPL  A  YLEVEL ,  PANEL_NONE, 
PANEL_LABEL_IMAGE,  &falter_pixrect, 

PANELNOTIF  YPROC ,  falter_proc, 

0); 


/*  Add  Button  */ 

bold  =  pf_open("/usr/lib/fonts/fixedwidthfonts/screen.b.l6B); 
panel_create_item(control_panel ,  PANEL_BUTTON, 
PANELNOTIFYPROC,  call_add, 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Add  Fault",  11,  bold), 

0); 

/*  Annotate  Button  */ 


panel  create_item(control_panel,  PANEL_BUTTON, 
PAI’lEL  NOTIF Y  PROC ,  call_annotate, 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Annotate",  11,  bold), 

0); 

I*  Error  Button  */ 

panel  create  item(control_panel,  PANEL  BUTTON, 
PANEL JnOTEFY_PROC  ,  call_error,” 

P ANEL_L ABEL_IM A GE ,  panel_button_image( 
control j»nel,  "Error",  11,  bold), 

0); 
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/*  FLOC  to  LocCond  Button  */ 


panel_create_item(control_panel ,  PANEL_BUTTON, 
PANElJnOTEFY_PROC,  call_error_Toc, 

P ANEL_L ABEL_IM AG  E ,  panel_button_image( 
control_panel,  "Error  Loc.",  11,  bold), 

0); 

/*  using  entry  indicated  by  ErrNum  *1 

panelcreate  item(control_panel ,  PANEL_BUTTON, 
PANELNOTIF  Y_PROC ,  call_get_error, 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Get  Error",  11,  bold), 

0); 

/*  Implication  Button  */ 

panel  create  item(control_panel,  PANELBUTTON, 
PANELNOTIF  YPROC ,  calljmplication, 
PANEL  LABEL  IMAGE,  panel_button_image( 
control_panel,  "Implication",  11,  bold), 

0); 

/*  Left  Button  */ 

panel  create  i tem (control_panel ,  PANEL  BUTTON, 
P ANEL  NOTIF Y  PROC ,  calljeft, 

PANEL  LABEL  IMAGE,  panel_button_image( 
control_panel,  "Left",  11,  bold), 

0); 

/*  Module  Button  */ 

panel_create_item(control_panel,  PANEL  BUTTON, 
PANELNOTIF  YPROC ,  call^goto,  ” 

PANEL  LABEL  IMAGE,  panel_button_image( 
control_panel,  "Goto",  11,  bold), 

PANEL  ITEM  X,  77, 

PANEL_ITEM~Y,  35, 

0); 

/*  Node  Button  */ 
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panel_create  item(control_panel,  PANEL  BUTTON, 
PANElJnOTIFY  PROC  ,  call_node,” 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Node",  11,  bold), 

0); 

/*  Prior  Button  */ 

panel_create_item(control_panel,  PANEL  BUTTON, 
PANELNOTIF Y_PROC ,  call_prior,~ 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Prior-,  11,  bold), 

0); 

/*  Right  Button  */ 

panel_create_item(control_panel,  PANEL_BUTTON, 
PANEL  NOTIF Y  PROC ,  calljight, 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Right",  11,  bold), 

0); 

/*  Set  Value  Button  *1 

panel_create_item(control_panel,  P ANEL  BUTTON , 
P ANEL_NOTIF Y  PROC ,  call_set_value, 
PANEL_LABEL_IMAGE,  panel_button_image( 
controljpanel,  "Set  Value",  11,  bold), 

0); 

/*  Type  Button  */ 

panel_create_item(controljpanel,  P ANEL  BUTTON , 
PANEL  NOTIFY  PROC,  call_error_type, 
PANEL_LABEL_IMAGE,  panel_button_image( 
control_panel,  "Error  Type",  11,  bold), 

0); 

/*  Violation  Button  */ 

panel_create  item(control_panel,  PANEL_BUTTON, 
PANEL_NOTIFY_PROC,  call_violation_set, 
PANEL_LABEL_IMAGE,  panel_button_image( 
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control_panel,  "Violation",  11,  bold), 


0); 


/*  This  is  the  input  string  code  for  falter  */ 

falter  string  item  =  panel_create  item(control_panel, 
PANEL JTEXT,  PANEL_LABEL_STRING , 
"Falter  input  string:", 

PANEL_ VALUE  DISPLAY  LENGTH,  50, 
PANEL_ITEM_X”  94, 

PANEL_ITEM_Y,  70, 

0); 

window_fit(base_ffame) ; 
window_main_loop(base_frame) ; 
exit(0); 

} 

static  void 
calladdO 
{ 

char  falter_string_buffer[8 1  ] ; 
sprintf(falter_string_buffer,  "a\n", 
panel_get_value(falter_string_item)>; 
if  (falter  run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)) ; 

} 

panel_set_value(falter_string  item,  ""); 

} 

static  void 
call_annotate() 

{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "c  %s\n", 
panel jget_value(falter_string_item)) ; 
if  (falter_run  =  =  1)  { 

tty s w_inpu t ( tty _sw ,  falter_string_buffer,  strlen( 
falter_string_buffer)) ; 

} 
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panel_set_value(falter_string_item , 


static  void 
callerrorO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter__string_buffer,  "e  %s\n", 
panel _get_value(falter_string_item)) ; 
if  (falter_run  ==  1)  { 

ttyswjnput(tty_sw,  falter_string_buffer,  strlen( 
falter_string  buffer)); 

} 

panel_set_value(falter_string_item,  ""); 


static  void 
call_error_locO 
{ 

char  falter_string_buffer[8 1  ] ; 
sprintf(falter_string_buffer,  "f  %s\n", 
panel _get^value(falter_string_item)); 
if  (falter  run  =  =  1)  { 

ttysw_input(tty_sw ,  falter_string_buffer,  strlen( 
falterstringbuffer)) ; 

} 

panel_set_value(falter_string_item,  ""); 

static  void 
call_get  errorO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "g  %s\n", 
panel _get^value(falter_string_item)) ; 
if  (falter jrun  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
faltcr_string_buffer)) ; 

} 

panel_set_value(falter_string_item,  ""); 


call  implicationO 

{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "i  %s\n", 
panel_jet_value(falter_string_item)) ; 
if (falterjun  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter  string  buffer)); 

} 

panel_set  value(falter  string  item,  ""); 

} 

static  void 
call  leftO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "l\n", 

panelj»et_value(falter_string_item)); 
if  (falter  run  =  =  1)  { 

ttysw_input(tty_sw,  falter  string  buffer,  strlen( 
falterstringbuffer)) ; 

} 

panel_set_value(falter_string_item,  ""); 

} 

static  void 
ca!l_goto() 

{ 

char  falter_in_value[81]; 
char  falter_string_bufferI81]; 

strcpy(falter_in_value,panel_get_value(falter_string_item)); 
sprintf(falter_string_buffer,  "m  % s\n " , falter_in_value) ; 
curblock  =  fmdahbk(falter_in_value); 
if  (falter_run  ==  1  &&  curblock  !  =  NULL)  { 
ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)); 

} 

else  {curblock  =  *(ahprocs+ahlen-l); 

/*  eventually,  we’ll  put  a  pop-up  error  message  here  */ 

} 

drawgraph(curblock-  >  abkgrph); 
panel  set_value(falter  string  item,  ""); 

} 
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static  void 
call  nodeO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "n  %s\n", 
panel _get_value(falter_string_item)) ; 
if  (falter_run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string  buffer)); 

} 

panel_set_value(falter  string  item,  ""); 

} 

static  void 
calljpriorO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "p\n", 
panel  get  value(falter  string  item)); 
if  (falter  run  =  =  1)  { 

tty sw_input(tty_sw ,  falter_string_buffer,  strlen( 
falter_string_buffer)) ; 

} 

panel_set_value(falter_string_item,  ""); 

} 

static  void 
calljrightO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "r\n", 
panel _get_value(falter_string_item)); 
if  (falter_run  =  =  1)  { 

ttysw_input(tty_sw,  faiter_string_buffer,  strlen( 
falter_string  buffer)); 

} 

panel  set  value(falter  string_item,  ""); 

} 

static  void 
call  set_value() 

{ 

char  falter_string_buffer[8 1  ] ; 
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sprintf(falter_string_buffer,  "s\n", 
panel^get_value(falter_string_item)) ; 
if  (falter_run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter  string  buffer)); 

} 

panel_set_value(falter_string_item,  ""); 


static  void 
call_error_typeO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "t  %s\n", 
panel_get_value(falter_string_item)) ; 
if  (falter  run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)) ; 

} 

panel_set_value(falter_string_item,  ""); 

} 

static  void 
call_violation_setO 
{ 

char  falter_string_buffer[81]; 
sprintf(falter_string_buffer,  "v  %s\n", 
panel^get_value(falter_string_item)); 
if  (falter_run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)); 

} 

panel  set_value(falter_string_item,  ""); 

} 


static  void 

falter_proc(item,  value,  event) 
Panel  item  item; 
int  value; 

Event  *event; 

{ 

char  falter_string_buffer[81]; 
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if(event_action(event)  =  = 

MS_RIGHT  &&  event_is_down(event))  { 
switch(value)  { 
case  0: 

sprintf(falter_string_buffer,  "falter  %s\n", 
panel_get_value(falter_string_item)) ; 
if  (falter  run  =  =  0)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)); 
falter_run  =  1; 

} 

panel_set_value(falter_stringjtem, 
break; 
case  1: 

sprintf(falter_string_buffer,  "h\n", 
panel_get_value(falter_string_item)) ; 
if  (falterrun  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)); 

} 

panel_set_value(falter_string_item, 
break; 
case  2: 

sprintf(falter_string_buffer,  "w  %s\n", 
panel_get_value(falter_string_item)); 
if  (falter_run  ==  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter  string_buffer)); 

} 

panel_set_value(falter_string_item,  ""); 
break; 
case  3: 

sprintf(falter_string_buffer,  "q\n", 
panel jget_value(falter_string_item)); 
if  (falter_run  =  =  1)  { 

ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
falter_string_buffer)); 
falter_run  =  0; 

} 

panel_set_value(falter_string_item,  ""); 
sprintf(falter_string_buffer,  "clear\n", 
panel _get_value(falter_string_item)) ; 
ttysw_input(tty_sw,  falter_string_buffer,  strlen( 
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falter_string_buffer)); 

break; 

} 

} 

} 

jfifdef  ACFGGRAPH 
static  void 

drawline(curx ,  cury ,  finalx ,  finaly ) 
int  curx,  cury,  finalx,finaly; 

{ 

#ifdef  DEBUG 

printf("Begin  Drawline  Function\n"); 

printf("%d  %d  %d  %d\n",  curx,  cury,  finalx,  finaly); 

#endif  DEBUG 

pw_vector(pw,  curx,  cury,  finalx,  finaly,  PIX_SRC,  1); 
#ifdef  DEBUG 

printf("Leaving  drawline  function\n"); 

#endif  DEBUG 

} 


static  void 

drawcircle(curx,  cury) 
int  curx; 
int  cury; 

{ 

static  int  npts[l]=  {NUM  POINTS}; 
jfifdef  DEBUG 

printf("Begin  drawing  Circle\n"); 
tfendif  DEBUG 

pw_polygon_2(pw,  curx,  cury,  1,  npts,  vlistO,  PK  CLR,  NULLPR,  0, 

0); 

for(i  =  0;  i  <  (NUM_POINTS  -  1);  i++)  { 

pw_vector(pw,  vlistO[i].x  +  curx,  vlistO[i].y  +  cury, 
vlistO[i+l].x  +  curx,  vlistO[i+l].y  +  cury,  PIX  SRC,  1); 

} 


202 


#ifdef  DEBUG 

printf("Leaving  circle  function\n"); 
#endif  DEBUG 
} 

tfendif  ACFGGRAPH 


/*  TITLE 

*  AUTHORS 

*  DATE 

*  REVISED 

*  SYSTEM 

*  LANGUAGE 

*  COMPILER 

*  DESCRIPTION 

*  associated  with  it. 
*/ 


space  win.  c 

Vicki  Abel  and  Medio  Monti 
15  November  1990 
30  November  1990 
NPS  SUN  TAURUS 
SunView  and  C 
Unix  cc 

This  program  creates  the  spacer  frame  and  the  subwindows 


/*  SunView  header  files  needed  in  this  program.  */ 
^include  <suntool/sunview.h> 

^include  <  suntool/panel.h  > 

#include  <suntool/tty.h> 

^include  <  suntool/icon.h  > 

^include  <  suntool/scrollbar.h  > 

^include  <  pixrect/prline.  h  > 

^include  <stdio.h> 

^include  <math.h> 


^define  BASEFRAMEWINX  525 

^define  BASEFRAMEWINY  205 

#define  TTYWINHEIGHT  794 

^define  TTYWINWIDTH  1000 

^define  PANELWINH  EIGHT  100 

^define  PANELWINWIDTH  1000 

^define  PANELWINX  0 

^define  PANELXGAP  27 


/*  type  declarations  *1 
Frame  baseframe; 

Panel  control_panel; 

Panelitem  menu; 

Panelitem  input_string; 

Tty  tty_sw; 

Icon  spacer_icon; 

/*  Procedures  used  by  buttons  and  menus  */ 
static  void  call_right0‘, 
static  void  spacer_procQ; 
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/*  This  is  the  icon  for  the  frame  */ 
static  short  icon_imageQ  =  { 

^include  "spacer. icon" 

}; 

mpr_static(spacer_pixrect,  64,  64,  1,  icon_image); 

main(argc,  argv) 
int  argc; 
char  *argvQ; 

{ 

spacer  icon  =  icon_create(ICON_IMAGE,  &spacer_pixrect,  0); 

/*  this  is  the  base  frame  for  the  application  */ 
baseframe  =  windo w_create(NULL ,  FRAME, 

WIN  X,  BASEFRAMEWINX,  /*  sets  x  position  */ 

WINY,  BASEFRAME  WINY,  /*  sets  y  position  */ 

FRAME  LABEL,  "Spacer  Window  1.0",/*  frame  label  */ 
FRAME_ICON,  spacer_icon,  /*  icon  used  */ 

FRAME  ARGS,  argc,  argv,  /*  main  args  */ 

0); 

/*  this  is  a  tty  subwindow  */ 

tty_sw  =  window  create(base  frame,  TTY, 

WINHEIGHT,  TTYWINHEIGHT, 

WINWIDTH,  TTYWINWIDTH, 

0); 

/*  this  is  a  panel  subwindow  */ 

control_panel  =  window_create(base_frame,  PANEL, 

WINBELO W ,  «y_sw, 

WINHEIGHT,  PANELWINHEIGHT, 

WINWIDTH,  PANELWINWIDTH, 

WIN_X,  PANELWINX, 

PANEL  ITEM  X_GAP,  PANELXGAP, 

0); 

window_fit(base_frame) ; 
window_main_loop(base_frame) ; 

exit(0) ; 

} 
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APPENDIX  E 


This  appendix  contains  the  source  code  for  "getangle.p".  Italicized  text  indicates  the 
corresponding  acfg  node  numbers. 


program  getangle  (input, output); 
const  Pi  =  3.1415926536; 
var  ang,XO,YO,XT,YT,W,L:real; 

function  Angle(XO,YO,XT,YT,WT,LT:real):real; 

var  SA,SB,SC,SD,AX,AY,  BX.BY,  CX,CY,  DX,DY:  real; 

HalfWidth,  HalfLength:  real; 


function  Slope  (Xl,Yl,X2,Y2:real):  real; 


end; 


n 

node  1 

Slope  :  =  (Y2  -  Yl)  /  (X2  -  XI); 

node  2 

n 

node  4 

HalfWidth  :=  WT/2; 

node  5 

HalfLength  :=  LT/2; 

node  6 

AX  :=  XT  -  HalfWidth; 

node  7 

AY  :=  YT  +  HalfLength; 

node  8 

DX  :=  XT  +  HalfWidth; 

node  9 

DY  :=  YT  -  HalfLength; 

node  10 

BX  :=  DX; 

node  11 

BY  :  =  AY; 

node  12 

CX  :=  AX; 

node  13 

CY  :=  DY; 

node  14 

SA  :=  Slope(XO,YO,AX,AY); 

nodes  15  A  16 

SA  :=  arctan(SA); 

nodes  17  &  18 

SD  :=  Slope(XO,YO,DX,DY); 

nodes  19  A  20 

SD  :=  arctan(SD); 

nodes  21  A  22 

SC  :=  Slope(XO,YO,CX,CY); 

nodes  23  A  24 

SC  :=  arctan(SC); 

nodes  25  A  26 

SB  :=  Slope(XO,YO,BX,BY); 

nodes  27  A  28 

SB  :  =  arctan(SB); 

nodes  29  A  30 

if  ((YO  >  BY)  and  (XO  >  BX))  then 

node  31 

Angle  :  =  abs(SD  -  SA) 

nodes  32  A  33 

else  if  ((XO  <  CX)  and  (YO  <  CY))  then 

node  34 

Angle  :  =  abs(SA  -  SD) 

nodes  35  A  36 

else  if  ((YO  >  AY)  and  (XO  <  AX))  then 

node  37 

Angle  :  =  abs(SC  -  SB) 

nodes  38  A  39 

else  if  ((YO  >  DY)  and  (XO  >  DX))  then 

node  40 
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Angle  :  =  abs(SB  -  SC) 

nodes  41  A  42 

else  if  XO  >  BX  then 

node  43 

Angle  :  =  abs(SD  +  SB) 

nodes  44  A  45 

else  if  XO  <  AX  then 

node  46 

Angle  :  =  abs(SA  +  SC) 

nodes  47  A  48 

else  if  (YO  >  =  AY)  then 

node  49 

if  (XO  =  AX)  then 

node  50 

Angle  :  =  Pi/2  -  abs(SB) 
else  if  (XO  <  BX)  then 

nodes  51  A  52 

node  53 

Angle  :  =  Pi  -  abs(SA)  -  abs(SB) 
else 

nodes  54,  55  A  56 

Angle  :  =  Pi/2  -  abs(SA) 

nodes  57  A  58 

else  if  (YO  <  =  CY)  then 

node  59 

if  (XO  =  DX)  then 

node  60 

Angle  :  =  Pi/2  -  abs(SC) 

nodes  61  A  62 

else  if  (XO  >  CX)  then 

node  63 

Angle  :  =  Pi  -  abs(SD)  -  abs(SC) 
else 

nodes  64,  65  A  66 

Angle  :  =  Pi/2  -  abs(SD) 
else 

nodes  67  A  68 

Angle  :  =  2  *  Pi; 

end; 

node  69 

begin 

node  71 

readln(XO,YO,XT,YT,W,L); 

node  72 

ang:=  Angle(XO,YO,XT,YT,W,L); 

nodes  73  A  74 

wnteln(’Observed  angle  is  ’,ang); 

end. 

node  75 
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APPENDIX  F 


This  appendix  contains  a  copy  of  the  file  "reacher_out". 

getangle 

0 

true 

1 

3 

program  getangle  (input, output); 

const  Pi  =  3.1415926536; 

var  ang,XO,YO,XT,YT,W,L:real; 

Angle 

71 
70 

72 
-1 

true 

false 

0 


7 

72 

71 

73 
-1 

true 

false 

0 

readln(XO,YO,XT,YT,W,L) 

2 

73 

72 

74 
-1 

true 
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false 

1 

Angle 

Angle(XO,YO,XT,YT,W,L) 

11 

74 

72 

75 
-1 

true 

false 

0 

ang:=  Angle(XO,YO,XT,YT,W,L); 

1 

75 

73 
-1 
-1 

true 

false 

0 

writeln(’Observed  angle  is  \ang) 

2 

Angle 

1 

true 

1 

3 

function  Angle(XO,YO,XT,YT,WT,LT:real):real; 
var  SA  CB,SC,SD,AX,AY,  BX,BY,  CX.CY,  DX,DY: 
HalfW*-ai,  HalfLength:  real; 

Slope 

4 
13 

5 
-1 

true 

false 

0 
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7 

5 
14 

6 
-1 

true 

false 

0 

HalfWidth 


=  WT/  2; 


1 

6 

15 

7 

-1 

true 

false 

0 

HalfLength 


=  LT  /  2; 


1 

7 
16 

8 
-1 

true 

false 

0 

AX 


=  XT  -  HalfWidth; 


1 

8 

17 

9 

-1 

true 

false 

0 

AY 


=  YT  +  HalfLength; 


1 

9 

18 


210 


10 

-1 

true 

false 

0 

DX  :=  XT  +  HalfWidth; 

1 

10 

19 
11 
-1 

true 

false 

0 

DY  :=  YT  -  HalfLength; 

1 

11 

20 
12 
-1 

true 

false 

0 

BX  :=  DX; 

1 

12 

21 

13 

-1 

true 

false 

0 

BY  :=  AY; 

1 

13 
22 

14 
-1 

true 
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false 

0 

CX  :=  AX; 

1 

14 

23 

15 
-1 

true 

false 

0 

CY  :=  DY; 

1 

15 

24 

16 
-1 

true 

false 

1 

Slope 

Slope(XO,YO,AX,AY) 

11 

16 

24 
17 
-1 

true 

false 

0 

SA  :=  Slope(XO,YO,AX,AY); 

1 

17 

25 

18 
-1 

true 

false 

0 
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arctan(SA) 


11 

18 

25 
19 
-1 

true 

false 

0 

SA  :  =  arctan(SA); 

1 

19 

26 

20 
-1 

true 

false 

1 

Slope 

Slope(XO,YO,DX,DY) 

11 

20 

26 

21 

-1 

true 

false 

0 

SD  :=  Slope(XO,YO,DX,DY); 

1 

21 

27 

22 

-1 

true 

false 

0 

arctan(SD) 


11 

22 

27 
23 
-1 

true 

false 

0 

SD  :=  arctan(SD); 

1 

23 

28 

24 
-1 

true 

false 

1 

Slope 

Slope(XO,YO,CX,CY) 

11 

24 
28 

25 
-1 

true 

false 

0 

SC  :=  Slope(XO,YO,CX,CY); 

1 

25 
29 

26 
-1 

true 

false 

0 

arctan(SC) 

11 

26 
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29 
27 
-1 

true 

false 

0 

SC  :  =  arctan(SC); 

1 

27 

30 

28 
-1 

true 

false 

1 

Slope 

Slope(XO,YO,BX,BY) 

11 

28 

30 
29 
-1 

true 

false 

0 

SB  :=  Slope(XO,YO,BX,BY); 

1 

29 

31 

30 
-1 

true 

false 

0 

arctan(SB) 

11 

30 

31 
31 
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-1 

true 

false 

0 

SB  :  =  arctan(SB); 

1 

31 

32 
32 
34 

((YO  >  BY)  and  (XO  >  BX)) 
not  ( ((YO  >  BY)  and  (XO  >  BX)) ) 
0 

if  ((YO  >  BY)  and  (XO  >  BX))  then 

12 

32 

33 
33 
-1 

true 

false 

0 

abs(SD  -  SA) 

11 

33 

34 
-1 
-1 

true 

false 

0 

Angle  :=  abs(SD  -  SA) 

1 

34 

35 
35 
37 

((XO  <  CX)  and  (YO  <  CY)) 
not  ( ((XO  <  CX)  and  (YO  <  CY)) ) 
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0 

if  ((XO  <  CX)  and  (YO  <  CY))  then 

12 

35 

36 
36 
-1 

true 

false 

0 

abs(SA  -  SD) 

11 

36 

37 
-1 
-1 

true 

false 

0 

Angle  :  =  abs(SA  -  SD) 

1 

37 

38 
38 
40 

((YO  >  AY)  and  (XO  <  AX)) 
not  ( ((YO  >  AY)  and  (XO  <  AX)) ) 
0 

if  ((YO  >  AY)  and  (XO  <  AX))  then 

12 

38 

39 
39 
-1 

true 

false 

0 

abs(SC  -  SB) 
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11 

39 

40 
-1 
-1 

true 

false 

0 

Angle  :  =  abs(SC  -  SB) 

1 

40 

41 
41 
43 

((YO  >  DY)  and  (XO  >  DX)) 
not  ( ((YO  >  DY)  and  (XO  >  DX)) ) 
0 

if  ((YO  >  DY)  and  (XO  >  DX))  then 

12 

41 

42 
42 
-1 

true 

false 

0 

abs(SB  -  SC) 

11 

42 

43 
-1 
-1 

true 

false 

0 

Angle  :  =  abs(SB  -  SC) 

1 

43 

44 
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44 

46 

XO  >  BX 
not  (  XO  >  BX  ) 

0 

if  XO  >  BX  then 

12 

44 

45 
45 
-1 

true 

false 

0 

abs(SD  +  SB) 

11 

45 

46 
-1 
-1 

true 

false 

0 

Angle  :  =  abs(SD  +  SB) 
1 

46 

47 
47 
49 

XO  <  AX 
not  (  XO  <  AX  ) 

0 

if  XO  <  AX  then 

12 

47 

48 
48 
-1 

true 
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false 

0 

abs(SA  +  SC) 

11 

48 

49 
-1 
-1 

true 

false 

0 

Angle  :  =  abs(S A  +  SC) 
1 

49 

50 
50 
59 

(YO  >  =  AY) 
not  ( (YO  >  =  AY) ) 

0 

if  (YO  >  =  AY)  then 

12 

50 

51 
51 
53 

(XO  =  AX) 
not  (  (XO  =  AX) ) 

0 

if  (XO  =  AX)  then 

12 

51 

52 
52 
-1 

true 

false 

0 

abs(SB) 


220 


11 

52 

53 
-1 
-1 

true 

false 

0 

Angle  :  =  Pi/2  -  abs(SB) 
1 

53 

54 
54 
57 

(XO  <  BX) 
not  ( (XO  <  BX) ) 

0 

if  (XO  <  BX)  then 

12 

54 

55 
55 
-1 

true 

false 

0 

abs(SA) 

11 

55 

55 

56 
-1 

true 

false 

0 

abs(SB) 

11 

56 

56 
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-1 

-1 

true 

false 

0 

Angle  :  =  Pi  -  abs(SA)  -  abs(SB) 
1 

57 

57 

58 
-1 

true 

false 

0 

abs(SA) 

11 

58 

58 
-1 
-1 

true 

false 

0 

Angle  :  =  Pi/2  -  abs(SA) 

1 

59 

59 

60 
69 

(YO  <  =  CY) 
not  ( (YO  <  =  CY) ) 

0 

if  (YO  <  =  CY)  then 

12 

60 

60 

61 

63 

(XO  =  DX) 
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not  (  (XO  =  DX) ) 

0 

if  (XO  =  DX)  then 

12 

61 

61 

62 

-1 

true 

false 

0 

abs(SC) 

11 

62 

62 

-1 

-1 

true 

false 

0 

Angle  :  =  Pi/2  -  abs(SC) 

1 

63 
62 

64 
67 

(XO  >  CX) 
not  ( (XO  >  CX) ) 

0 

if  (XO  >  CX)  then 

V. 

64 
63 

65 
-1 

true 

false 

0 

abs(SD) 
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11 

65 

63 

66 
-1 

true 

false 

0 

abs(SC) 

11 

66 

64 
-1 
-1 

true 

false 

0 

Angle  :  =  Pi  -  abs(SD)  -  abs(SC) 
1 

67 

65 

68 
-1 

true 

false 

0 

abs(SD) 

11 

68 

66 
-1 
-1 

true 

false 

0 

Angle  :  =  Pi/2  -  abs(SD) 

1 

69 

67 
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-1 

-1 


true 

false 

0 

Angle  :  =  2  *  Pi; 


1 

Slope 

4 

true 

0 

1 

function  Slope  (Xl,Yl,X2,Y2:real):  real; 
1 

10 

2 

-1 


true 

false 

0 


7 

2 

11 

-1 

-1 

true 

false 

0 

Slope  :=  (Y2  -  Yl)  /  (X2  -  XI); 

1 
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APPENDIX  G 


This  appendix  contains  a  copy  of  the  file  "walker_out". 


getangle 

0 

true 

1 

3 

program  getangle  (input, output); 
const  Pi  =  3.1415926536; 
var  ang,XO,YO,XT,YT,W,L:real; 
Angle 
72 
70 
74 
-1 

true 

false 

0 

readln(XO,YO,XT,YT,W,L) 

2 

74 

72 

75 
-1 

true 

false 

1 

Angle 

ang:=  Angle(XO,YO,XT,YT,W,L); 

1 

75 

73 
-1 
-1 
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true 

false 

0 

writeln(’Observed  angle  is  \ang) 

2 

Angle 

1 

true 

1 

3 

function  Angle(XO,YO,XT,YT,WT,LT:real):real; 
var  SA,SB,SC,SD,AX,AY,  BX,BY,  CX.CY,  DX,DY: 
HalfWidth,  HalfLength:  real; 

Slope 

5 
13 

6 
-1 

true 

false 

0 

HalfWidth  :  =  WT  /  2; 


1 

6 

15 

7 

-1 


true 

false 

0 

HalfLength  :=  LT  /  2; 


1 

7 
16 

8 
-1 


true 

false 

0 

AX  :=  XT  -  HalfWidth; 
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1 

8 

17 
9 
-1 

true 

false 

0 

AY  :=  YT  +  HalfLength; 

1 

9 

18 

10 
-1 

true 

false 

0 

DX  :  =  XT  +  HalfWidth; 

1 

10 

19 
11 
-1 

true 

false 

0 

DY  :  =  YT  -  HalfLength; 

1 

11 

20 
12 
-1 

true 

false 

0 

BX  :=  DX; 

1 

12 

21 
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13 

-1 

true 

false 

0 

BY  :=  AY; 

1 

13 
22 

14 
-1 

true 

false 

0 

CX  :=  AX; 

1 

14 

23 
16 
-1 

true 

false 

0 

CY  :=  DY; 

1 

16 

24 
18 
-1 

true 

false 

1 

Slope 

SA  :=  Slope(XO,YO,AX,AY); 


1 

18 

25 

20 

-1 
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true 

false 

0 

SA  :  =  arctan(SA); 

1 

20 

26 

22 

-1 

true 

false 

1 

Slope 

SD  :=  Slope(XO,YO,DX,DY); 


1 

22 

27 
24 
-1 

true 

false 

0 

SD  :=  arctan(SD); 

1 

24 

28 
26 
-1 

true 

false 

1 

Slope 

SC  :  =  Slope(XO,YO,CX,CY); 


1 

26 

29 

28 

-1 

true 
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false 

0 

SC  :=  arctan(SC); 


1 

28 

30 

30 

-1 

true 

false 

1 

Slope 

SB  :=  Slope(XO,YO,BX,BY); 

1 

30 

31 
31 
-1 

true 

false 

0 

SB  :=  arctan(SB); 

1 

31 

32 

33 

34 

((YO  >  BY)  and  (XO  >  BX)) 

not  ( ((YO  >  BY)  and  (XO  >  BX)) )  and  ((YO  >  BY)  and  (XO  >  BX)) 
0 

if  ((YO  >  BY)  and  (XO  >  BX))  then 

12 

33 

33 

999999 

-1 

((YO  >  BY)  and  (XO  >  BX)) 
false 
0 


Angle  :  =  abs(SD  -  SA) 


1 

34 

35 

36 

37 

((XO  <  CX)  and  (YO  <  CY))  and  ((XO  <  CX)  and  (YO  <  CY» 
not  ( ((XO  <  CX)  and  (YO  <  CY)) )  and  not  ( ((YO  >  BY)  and  (XO  >  BX)) ) 
0 

if  ((XO  <  CX)  and  (YO  <  CY))  then 


12 

36 

36 

999999 

-1 

((XO  <  CX)  and  (YO  < 
false 
0 

Angle  :  =  abs(SA  -  SD) 


CY)) 


1 

37 

38 

39 

40 

((YO  >  AY)  and  (XO  <  AX))  and  ((YO  >  AY)  and  (XO  <  AX)) 
not  ( ((YO  >  AY)  and  (XO  <  AX)) )  and  ((YO  >  AY)  and  (XO  <  AX)) 
0 

if  ((YO  >  AY)  and  (XO  <  AX))  then 


12 

39 

39 

999999 

-1 

((YO  >  AY)  and  (XO  < 
false 
0 

Angle  :  =  abs(SC  -  SB) 


AX)) 
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1 

40 

41 

42 

43 

((YO  >  DY)  and  (XO  >  DX))  and  ((YO  >  DY)  and  (XO  >  DX» 
not  (  ((YO  >  DY)  and  (XO  >  DX)) ) 


if  ((YO  >  DY)  and  (XO  >  DX))  then 

12 

42 

42 

999999 

-1 

((YO  >  DY)  and  (XO  >  DX)) 
false 
0 

Angle  :  =  abs(SB  -  SC) 

1 

43 

44 

45 

46 

XO  >  BX  and  XO  >  BX  and  YO  >  =  DY  and  YO  <  =  BY  and  YO  >  =  DY  and 
YO  <  =  BY 

not  (  XO  >  BX  )  and  c  YO  >  =  DY  and  YO  <  =  BY  and  YO  <  =  BY  and  YO  >  = 
DY 
0 

if  XO  >  BX  then 

12 

45 

45 

999999 

-1 

XO  >  BX  and  YO  >  =  DY  and  YO  <  =  BY 
false 
0 

Angle  :  =  abs(SD  +  SB) 

1 
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46 

47 

48 

49 
XO 


AX  and  YO  >  =  CY  and  YO  <  =  AY 

<  AX  )  and  XO  <  AX  and  YO  >  =  CY  and  YO  <  =  AY 


not  ( XO 
0 

if  XO  <  AX  then 

12 

48 

48 

999999 

-1 

XO  <  AX  and  YO  >  =  CY  and  YO  <  =  AY 
false 
0 

Angle  :  =  abs(SA  +  SC) 

1 

49 

50 
50 
59 

(YO  >  =  AY) 
not  ( (YO  >  =  AY) ) 

0 

if  (YO  >  =  AY)  then 

12 

50 

51 

52 

53 

(XO  =  AX)  and  (YO  >  =  AY) 
not  ( (XO  =  AX) )  and  (YO  >  =  AY) 

0 

if  (XO  =  AX)  then 

12 

52 

52 

999999 
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-1 

(XO  =  AX)  and  (YO  >  =  AY) 
false 
0 

Angle  :  =  Pi/2  -  abs(SB) 

1 

53 

54 
56 
58 

(XO  <  BX)  and  (XO  >  AX)  and  (YO  >  =  AY) 
not  (  (XO  <  BX) )  and  (XO  >  AX)  and  (YO  >  =  AY) 
0 

if  (XO  <  BX)  then 


12 

56 

55 

999999 

-1 

(XO  <  BX)  and  (XO  >  AX)  and  (YO  >  =  AY) 
false 
0 

Angle  :  =  Pi  -  abs(SA)  -  abs(SB) 


1 

58 

57 

999999 

-1 

(XO=BX)  and  (YO  >  =  AY) 
false 
0 

Angle  :  =  Pi/2  -  abs(SA) 


1 

59 

59 

60 
69 

(YO  <  =  CY) 

not  ( (YO  <  =  CY) )  and  (YO  <  AY)  and  (XO  >  =  AX)  and  (XO  <  =  BX) 
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0 

if  (YO  <  =  CY)  then 


12 

60 

60 

62 

63 

(XO  =  DX)  and  (YO  <  =  CY) 
not  ( (XO  =  DX) )  and  YO  <  =  CY 
0 

if  (XO  =  DX)  then 

12 

62 

61 

999999 

-1 

(XO  =  DX)  and  (YO  <  =  CY) 
false 
0 

Angle  :  =  Pi/2  -  abs(SC) 


1 

63 
62 
66 
68 

(XO  >  CX) 
not  ( (XO  > 

0 

if  (XO  >  CX) 


and  (YO  <  =  CY)  and  (XO  <  DX) 
CX) )  and  (YO  <  =  CY)  and  (XO  < 

then 


DX) 


12 

66 

63 

999999 

-1 

(XO  >  CX)  and  (YO  <  =  CY)  and  (XO  <  DX) 
false 
0 

Angle  :  =  Pi  -  abs(SD)  -  abs(SC) 
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1 

68 

65 

999999 

-1 


not  (  (XO  >  CX) )  and  (YO  <  =  CY)  and  (XO  <  DX) 
false 


0 

Angle  :  =  Pi/2  -  abs(SD) 


1 

69 

67 

999999 

-1 

not  (  'YO  <  =  CY) )  and  (YO  <  AY)  and  (XO  >  =  AX)  and  (XO  <  =  BX) 
false 
0 

Angle  :  =  2  *  Pi; 


1 

999999 

1 

-1 

-1 

false 

false 

0 


WALKER  added  exit  node 
10 

Slope 

4 

true 


0 

1 

function  Slope  (X!  ,Yl,X2,Y2:real):  real; 
2 
10 
-1 
-1 

true 

false 
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Slope  :=  (Y2  -  Yl)  /  (X2  -  XI); 


APPENDIX  H 


This  appendix  contains  a  copy  of  the  file  "getangle.list". 


program  getangle  (input, output); 
const  Pi  =  3.1415926536; 
var  ang,XO,YO,XT,YT,W,L:real; 

function  Angle(XO,YO,XT,YT,WT,LT:real):real; 
var  SA,SB,SC,SD,AX,AY,  BX,BY,  CX.CY,  DX,DY: 
HalfWidth,  HalfLength:  real; 


function  Slope  (Xl,Yl,X2,Y2:real):  real; 

begin  {Slope  when  true} 

1: 

2:  Slope  :  =  (Y2  -  Yl)  /  (X2  -  XI); 

end  {Slope} 


begin  {Angle  when  true} 


4: 

5: 

6: 

7: 

8: 

9: 

10: 

11: 

12: 

13: 

14: 

15: 

16: 

17: 

18: 

19: 

20: 

21: 


HalfWidth  :=  WT  /  2; 
HalfLength  :  =  LT  /  2; 

AX  :=  XT -HalfWidth; 

AY  :=  YT  +  HalfLength; 

DX  :=  XT  +  HalfWidth; 

DY  :=  YT  -  HalfLength; 

BX  :=  DX; 

BY  :=  AY; 

CX  :=  AX; 

CY  :=  DY; 
Slope(XO,YO,AX,AY) 

SA  :=  Slope(XO,YO,AX,AY); 
arctan(SA) 

SA  :=  arctan(SA); 
Slope(XO,YO,DX,DY) 

SD  :=  Slope(XO,YO,DX,DY); 
arctan(SD) 
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22:  SD  :  =  arctan(SD); 

23:  Slope(XO,YO,CX,CY) 

24:  SC  :=  Slope(XO,YO,CX,CY); 

25:  arctan(SC) 

26:  SC  :  =  arctan(SC); 

27:  Slope(XO,YO,BX,BY) 

28:  SB  :=  Slope(XO,YO,BX,BY); 

29:  arctan(SB) 

30:  SB  :  =  arctan(SB); 

31:  if  ((YO  >  BY)  and  (XO  >  BX))  then 
32:  abs(SD  -  SA) 

33:  Angle  :  =  abs(SD  -  SA) 
else 

34:  if  ((XO  <  CX)  and  (YO  <  CY))  then 
35:  abs(SA  -  SD) 

36:  Angle  :  =  abs(SA  -  SD) 
else 

37:  if  ((YO  >  AY)  and  (XO  <  AX))  then 
38:  abs(SC  -  SB) 

39:  Angle  :  =  abs(SC  -  SB) 
else 

40:  if  ((YO  >  DY)  and  (XO  >  DX))  then 
41:  abs(SB  -  SC) 

42:  Angle  :  =  abs(SB  -  SC) 
else 

43:  if  XO  >  BX  then 
44:  abs(SD  +  SB) 

45:  Angle  :=  abs(SD  +  SB) 
else 

46:  if  XO  <  AX  then 
47:  abs(SA  +  SC) 

48:  Angle  :  =  abs(SA  +  SC) 
else 

49:  if  (YO  >  =  AY)  then 
50:  if  (XO  =  AX)  then 
51:  abs(SB) 

52:  Angle  :  =  Pi/2  -  abs(SB) 
else 

53:  if  (XO  <  BX)  then 
54:  abs(SA) 

55:  abs(SB) 

56:  Angle  :  =  Pi  -  abs(SA)  -  abs(SB) 
else 
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57:  abs(SA) 

58:  Angle  :=  Pi/2  -  abs(SA) 
else 

59:  if  (YO  <  =  CY)  then 
60:  if  (XO  =  DX)  then 
61:  abs(SC) 

62:  Angle  :=  Pi/2  -  abs(SC) 
else 

63:  if  (XO  >  CX)  then 
64:  abs(SD) 

65:  abs(SC) 

66:  Angle  :  =  Pi  -  abs(SD)  -  abs(SC) 
else 

67:  abs(SD) 

68:  Angle  :  =  Pi/2  -  abs(SD) 
else 

69:  Angle  :  =  2  *  Pi; 

end  {Angle} 

begin  (getangle  when  true} 

71: 

72:  readln(XO,YO,XT,YT,W,L) 

73:  Angle(XO,YO,XT,YT,W,L) 

74:  ang:  =  Angle(XO,YO,XT,YT,W,L); 
75:  writeln(’Observed  angle  is  ’,ang) 
end  {getangle} 
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APPENDIX  I 


This  appendix  contains  a  copy  of  the  file  “spacer_in.l". 


(setq  progname  ’_getangle_) 

(defirn  _getangle_  (&rest  params) 

(prog  0 
(startup) 

(setq  routine  names  (list  ’getangle)) 

(setq  arg  list  nil) 

(setq  _t_arglist  nil) 

(setq  _t_retval  nil) 

(newvlist  0) 

(setq  typelist  (cons  nil  typelist)) 

(setq  FAULT_LIST  nil) 

(setq  FAULT_LIST  (append  FAULT_LIST  ’((0  line_42  "mis-substitution  of  SC  for  SD 
in  this  assignment”  Anglel  13  (NE  (varval  varlist  ’(W))  0)  (uni  AND  (uni_AND  (GT 
(varval  varlist  ’(YO))  (varval  varlist  ’(DY)))  (GT  (varval  varlist  ’(XO))  (varval  varlist 
’(DX))))  (uni_AND  (GT  (varval  varlist  ’(YO))  (varval  varlist  ’(DY)))  (GT  (varval  varlist 
’(XO))  (varval  varlist  ’(DX)))))  (varval  varlist  ’(Angle))  "Obs  Cond  1") ))) 

(setq  Anglel  nil) 

(cond  (FAULT_LIST  (getfault  FAULT JLIST))) 

(patom  "initialize  debug  options") 

(terpr) 

(setq  linenum  1)  (execl)  (cond  (swln  (go  _t_switch))) 
getangle 

line_l  (exec  1)  (cond  (swln  (go  _t_switch))) 

(setq  entry_asserts  (cons  ’(t)  entry_asserts)) 

(setq  exit_asserts  (cons  ’(t)  exit_asserts)) 

(addvar  ’L  ’real) 

(addvar  ’W  ’real) 

(addvar  ’YT  ’real) 

(addvar  ’XT  ’real) 

(addvar  ’YO  ’real) 

(addvar  ’XO  ’real) 

(addvar  ’ang  ’real) 

(cond  (in_verif_mode  (initialize_variables  t)) 

(t  (global_init))) 
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(cond  (static_chain 

(let  ((next  (car  static_chain))) 

(setq  static_chain  (cdr  static_chain)) 

(setq  swln  next) 

(go  _t_switch)))) 

(go  getangle.main) 

Angle.  static_chain 
(setq  static_chain  ’( Angle)) 

(go  getangle) 

Angle 

(set_up_proc  1) 

;top  of  function  Angle 

(addvar  ’LT  ’real) 

(addvar  ’WT  ’real) 

(addvar  ’YT  ’real) 

(addvar  ’XT  ’real) 

(addvar  ’YO  ’real) 

(addvar  ’XO  ’real) 

(setargs)  (setq  arg_list  nil) 

(addvar  ’Angle  ’real) 

(cond  ((not  at_top_level)  (changevar  ’(Angle)  ’©Angle))) 
(addvar  ’DY  ’HalfWidth) 

(addvar  ’DX  ’HalfWidth) 

(addvar  ’CY  ’HalfWidth) 

(addvar  ’CX  ’HalfWidth) 

(addvar  ’BY  ’HalfWidth) 

(addvar  ’BX  ’HalfWidth) 

(addvar  ’AY  ’HalfWidth) 

(addvar  ’AX  ’HalfWidth) 

(addvar  ’SD  ’HalfWidth) 

(addvar  ’SC  ’HalfWidth) 

(addvar  ’SB  ’HalfWidth) 

(addvar  ’SA  ’HalfWidth) 

(addvar  ’HalfLength  ’real) 

(cond  ((not  at_top_level)  (save_init_values)(do_entry_assertion) 
(init_localjparams)  (go  Angle,  exit))) 

(cond  (in_verif_mode  (initialize_variables  t))) 

(cond  (static_chain 

(let  ((next  (car  static_chain))) 

(setq  static_chain  (cdr  static_chain)) 

(setq  swln  next) 
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(go  _t_switch)))) 

(go  Angle,  main) 

(setq  entry_asserts  (cons  *(t)  entry_asserts)) 

(setq  exit_asserts  (cons  *(t>  exit_asserts)) 

Slope.  static_chain 

(setq  static_chain  ’( Angle  Slope)) 

(go  getangle) 

Slope 

(set  upjproc  2) 

;top  of  function  Slope 

(addvar  ’Y2  ’real) 

(addvar  ’X2  ’real) 

(addvar  ’Y1  ’real) 

(addvar  ’XI  ’real) 

(setargs)  (setq  arg_list  nil) 

(addvar  ’Slope  ’real) 

(cond  ((not  at_top_level)  (changevar  ’(Slope)  ’©Slope))) 

(cond  ((not  at_top_level)  (save_init_values)(do_entry_assertion) 

(init_local_params)  (go  Slope.exit))) 

(cond  (in_verif_mode  (initialize_variables  t))) 

(cond  (  tatic_chain 

(let  ((next  (car  static_chain))) 

(setq  static_chain  (cdr  static_chain)) 

(setq  swln  next) 

(go  _t_switch)))) 

(go  Slope,  main) 

(setq  entry  asserts  (cons  ’(t)  entry_asserts)) 

(setq  exit  asserts  (cons  ’(t)  exit_asserts)) 

Slope,  main 
(save_init_values) 

(do_entry_assertion) 

(cond  (swln  (go  t  switch))) 

;  begin 

line  lO  (exec  10)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(Slope)  ’(uni/  (uni-  (varval  varlist  ’(Y2))  (varval  varlist  ’(Yl)))  (uni-  (varval 
varlist  ’(X2))  (varval  varlist  ’(XI))))) 

(go  Slope.exit) 

;end 

Slope.exit 

(do_exit_assertion)  (cond  (swln  (go  _t_switch))) 

(check_routine_exit)(cond  (swln  (go  _t_switch))) 
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(set_ret_val  ’(varval  varlist  ’(Slope))) 

(closeproc) 

(setq  swln  (car  temp)) 

(go  _t_switch) 

Angle,  main 
(save_init_values) 

(do_entry_assertion) 

(cond  (swln  (go  _t_switch))) 

;begin 

line_13  (exec  13)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(HalfWidth)  ’(uni/  (varval  varlist  ’(WT))  2)) 
line_15  (exec  15)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(HalfLength)  ’(uni/  (varval  varlist  ’(LT))  2)) 
line_16  (exec  16)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(AX)  *(uni-  (varval  varlist  ’(XT))  (varval  varlist  ’(HalfWidth)))) 
line_17  (exec  17)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(AY)  ’(uni+  (varval  varlist  ’(YT))  (varval  varlist  ’(HalfLength)))) 
line_18  (exec  18)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(DX)  ’(uni+  (varval  varlist  ’(XT))  (varval  varlist  ’(HalfWidth)))) 
line_19  (exec  19)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(DY)  ’(uni-  (varval  varlist  ’(YT))  (varval  varlist  ’(HalfLength)))) 
line_20  (exec  20)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(BX)  ’(varval  varlist  ’(DX))) 
line_21  (exec  21)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(BY)  ’(varval  varlist  ’(AY))) 
line_22  (exec  22)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(CX)  ’(varval  varlist  ’(AX))) 
line_23  (exec  23)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(CY)  ’(varval  varlist  ’(DY))) 
line_24  (exec  24)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  arg  Jist)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(VAR_REF  XO)  arg_list)) 

(setq  arg_list  (cons  ’(VAR_REF  YO)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  AX)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  AY)  argjist)) 

(setq  arg_list  (reverse  argjist)) 

(setq  roudne_names  (cons  ’Slope  routine_names)) 

(setq  proclist  (cons  ’f_ret_0  proclist)) 

(cond  (in_verif_mode  (setq  atjopjevel  nil))) 

(go  Slope)  f_ret_0 

(cond  (_t_arglist  (setq  argjist  J_arglist)  (setq  _t_arglist  nil)) 


245 


(t  (setq  arg_list  nil))) 

(changevar  ’(SA)  ’(get_ret_val)) 

line_25  (exec  25)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  arg_list)  (setq  argjist  nil))) 

(setq  arg_list  (cons  ’(VARJREF  SA)  arg_list)) 

(setq  arg_list  (reverse  argjist)) 

(set  ret  val  (u_arctan  argjist)) 

(cond  (_t_arglist  (setq  arg_list  _t_arglist)  (setq  _t_arglist  nil)) 
(t  (setq  argjist  nil))) 

(changevar  ’(SA)  ’(get_ret_val)) 

line_26  (exec  26)  (cond  (swln  (go  J_switch))) 

(cond  (arg_list  (setq  J_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(VARREF  XO)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  YO)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  DX)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  DY)  argjist)) 

(setq  argjist  (reverse  argjist)) 

(setq  routine  names  (cons  ’Slope  routine_names)) 

(setq  proclist  (cons  ’f_ret_l  proclist)) 

(cond  (in_verif_mode  (setq  at  Jopjevel  nil))) 

(go  Slope)  f  ret  l 

(cond  (_t_arglist  (setq  arg_list  J_arglist)  (setq  J_arglist  nil)) 
(t  (setq  argjist  nil))) 

(changevar  ’(SD)  ’(get_ret_val)) 

line_27  (exec  27)  (cond  (swln  (go  J_switch))) 

(cond  (argjist  (setq  targlist  argjist)  (setq  arg_list  nil))) 

(setq  arg_list  (cons  ’(VAR  REF  SD)  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set_ret_val  (u_arctan  argjist)) 

(cond  (J_arglist  (setq  arg_list  J_arglist)  (setq  J_arglist  nil)) 
(t  (setq  arg_list  nil))) 

(changevar  ’(SD)  ’(get_ret_val)) 

Une_28  (exec  28)  (cond  (swln  (go  J_switch))) 

(cond  (arg_list  (setq  J_arglist  argjist)  (setq  argjist  nil))) 

(setq  argjist  (cons  ’(VAR_REF  XO)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  YO)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  CX)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  CY)  argjist)) 

(setq  argjist  (reverse  argjist)) 
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(setq  routinenames  (cons  ’Slope  routine_names)) 

(setq  proclist  (cons  ’f_ret_2  proclist)) 

(cond  (in_verif_mode  (setq  at_top_level  nil))) 

(go  Slope)  f_ret_2 

(cond  (J_arglist  (setq  argjist  _t_arglist)  (setq  _t_arglist  nil)) 
(t  (setq  arg_list  nil))) 

(changevar  ’(SC)  ’(get_rct_val)) 

line_29  (exec  29)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  arg_list)  (setq  argjist  nil))) 

(setq  arg_list  (cons  ’(VARREF  SC)  arg_list)) 

(setq  arg_list  (reverse  arg_list)) 

(set  ret  val  (u_arctan  argjist)) 

(cond  (_t_arglist  (setq  arg_list  _t_arglist)  (setq  _t_arglist  nil)) 
(t  (setq  argjist  nil))) 

(changevar  ’(SC)  ’(get_ret_val)) 

line_30  (exec  30)  (cond  (swln  (go  _t_switch))) 

(cond  (arg_list  (setq  _t_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  arg_list  (cons  ’(VAR  REF  XO)  arg_list)) 

(setq  arg_list  (cons  ’(VAR  REF  YO)  argjist)) 

(setq  arg_list  (cons  ’(VAR  REF  BX)  argjist)) 

(setq  argjist  (cons  ’(VAR  REF  BY)  arg_list)) 

(setq  argjist  (reverse  arg_list)) 

(setq  routine  names  (cons  ’Slope  routinejiames)) 

(setq  proclist  (cons  ’f_ret_3  proclist)) 

(cond  (in_verif_mode  (setq  at_topJevel  nil))) 

(go  Slope)  fret_3 

(cond  (_t_arglist  (setq  argjist  J_arglist)  (setq  J_arglist  nil)) 
(t  (setq  arg_list  nil))) 

(changevar  ’(SB)  ’(get_ret_val)) 

Une_31  (exec  31)  (cond  (swln  (go  J_switch))) 

(cond  (argjist  (setq  J_arglist  argjist)  (setq  argjist  nil))) 

(setq  argjist  (cons  ’(VAR_REF  SB)  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set_ret_val  (u_arctan  argjist)) 

(cond  (_t_arglist  (setq  arg_list  J_arglist)  (setq  J_arglist  nil)) 
(t  (setq  arg  list  nil))) 

(changevar  ’(SB)  ’(get_ret_val)) 

Une_32  (exec  32)  (cond  (swln  (go  J_switch))) 

;top  of  if 
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(cond  ((not  (predval  (uni_AND  (GT  (varval  varlist  ’(YO))  (varval  varlist  ’(BY)))  (GT 
(varval  varlist  ’(XO))  (varval  varlist  ’(BX))))))  (go  line_35)) 

(swln  (go  _t_switch))) 

line_33  (exec  33)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  arg_list  (cons  ’(uni-  (varval  varlist  ’(SD))  (varval  varlist  ’(SA)))  arg_list)) 

(setq  argjist  (reverse  arg_list)) 

(setretval  (u_fabs  argjist)) 

(cond  (_t_arglist  (setq  argjist  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  arg_list  nil))) 

(changevar  ’(Angle)  ’(get_ret_val)) 
line_l  (exec  1)  (cond  (swln  (go  _t_switch))) 

(go  Angle.exit) 

line_35  (exec  35)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (uni  AND  (LT  (varval  varlist  ’(XO))  (varval  varlist  ’(CX)))  (LT 
(varval  varlist  ’(YO))  (varval  varlist  ’(CY))))))  (go  line_38)) 

(swln  (go  tswitch))) 

Une_36  (exec  36)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  targlist  argjist)  (setq  arg_list  nil))) 

(setq  arg  list  (cons  ’(uni-  (varval  varlist  ’(SA))  (varval  varlist  ’(SD)))  arg  list)) 

(setq  argjist  (reverse  arg  list)) 

(set  ret  val  (u_fabs  arg  list)) 

(cond  (Jarglist  (setq  arg  list  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  arg  list  nil))) 

(changevar  ’(Angle)  ’(get_ret_val)) 

(go  line_l) 

line_38  (exec  38)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (uni_AND  (GT  (varval  varlist  ’(YO))  (varval  varlist  ’(AY)))  (LT 
(varval  varlist  ’(XO))  (varval  varlist  ’(AX))))))  (go  line_41)) 

(swln  (go  _t_switch))) 

line_39  (exec  39)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  J_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(uni-  (varval  varlist  ’(SC))  (varval  varlist  ’(SB)))  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set_ret_val  (u Jabs  argjist)) 

(cond  (_t_arglist  (setq  argjist  J_arglist)  (setq  J_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(get_ret_val)) 


248 


(go  line_l) 

line_41  (exec  41)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (uni__AND  (GT  (varval  varlist  ’(YO»  (varval  varlist  ’(DY)))  (GT 
(varval  varlist  ’(XO))  (varval  varlist  ’(DX)))»)  (go  line_44)) 

(swln  (go  _t_switch))) 

line_42  (exec  42)  (cond  (swln  (go  _t_switch))) 

(cond  (Anglel 

(setq  pc  (list  ’uni_and  pc  ’(uni_AND  (uni_AND  (GT  (varval  varlist  ’(YO))  (varval 
varlist  ’(DY)))  (GT  (varval  varlist  ’(XO))  (varval  varlist  ’(DX))))  (uni_AND  (GT  (varval 
varlist  ’(YO))  (varval  varlist  ’(DY)))  (GT  (varval  varlist  ’(XO))  (varval  varlist  ’(DX))))))) 
(setq  contamlist  ’((Angle  (uni_and  (NE  (varval  varlist  ’(W))  0)  (uni_AND 
(uni_AND  (GT  (varval  varlist  ’(YO))7varval  varlist  ’(DY)))  (GT  (varval  varlist  ’(XO)) 
(varval  varlist  ’(DX))))  (uni_AND  (GT  (varval  varlist  ’(YO))  (varval  varlist  ’(DY)))  (GT 
(varval  varlist  ’(XO))  (varval  varlist  ’(DX))))))))))) 

(cond  (argjist  (setq  _t_arglist  arg_list)  (setq  argjist  nil))) 

(setq  argjist  (cons  ’(uni-  (varval  varlist  ’(SB))  (varval  varlist  ’(SC)))  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set_ret_vai  (u Jabs  argjist)) 

(cond  (Jarglist  (setq  argjist  J_arglist)  (setq  J_arglist  nil)) 

(t  (setq  arg  jist  nil))) 

(changevar  ’(Angle)  ’(get  ret  val)) 

(go  linej) 

line_44  (exec  44)  (cond  (swln  (go  t  switch))) 

;top  of  if 

(cond  ((not  (predval  (GT  (varval  varlist  ’(XO))  (varval  varlist  ’(BX)))))  (go  line_47)) 
(swln  (go  J  switch))) 

line_45  (exec  45)  (cond  (swln  (go  J_switch))) 

(cond  (argjist  (setq  J  arglist  argjist)  (setq  argjist  nil))) 

(setq  argjist  (cons  ’(uni+  (varval  varlist  ’(SD))  (varval  varlist  ’(SB)))  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set_ret_val  (ujabs  argjist)) 

(cond  (_t_arglist  (setq  argjist  _t_arglist)  (setq  J_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(get_ret_val)) 

(go  linej) 

line_47  (exec  47)  (cond  (swln  (go  J_switch))) 

;top  of  if 

(cond  ((not  (predval  (LT  (varval  varlist  ’(XO))  (varval  varlist  ’(AX)))))  (go  line_50)) 
(swln  (go  J_switch))) 

line_48  (exec  48)  (cond  (swln  (go  J_switch))) 
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(cond  (arg_list  (setq  _t_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  arg_list  (cons  ’(uni+  (varval  varlist  ’(SA))  (varval  varlist  ’(SC)))  arg_list)) 

(setq  arg_list  (reverse  arg_list)) 

(set_ret_val  (u_fabs  arg_list)) 

(cond  (_t_arglist  (setq  arg_list  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  arg_list  nil))) 

(changevar  ’(Angle)  ’(get_ret_val)) 

(go  linel) 

line_50  (exec  50)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (GE  (varval  varlist  ’(YO))  (varval  varlist  ’(AY)))))  (go  line_59)) 
(swln  (go  _t_switch))) 

line_51  (exec  51)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (uni_EQ  (varval  varlist  ’(XO))  (varval  varlist  ’(AX)))))  (go  line_54)) 
(swln  (go  tswitch))) 

Une_52  (exec  52)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  jarglist  argjist)  (setq  argjist  nil))) 

(setq  arg  list  (cons  ’(VAR  REF  SB)  arg_list)) 

(setq  arg  list  (reverse  arg_list)) 

(set  ret  val  (u_fabs  arg  list)) 

(cond  (_t_arglist  (setq  arg  list  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  arg  list  nil))) 

(changevar  ’(Angle)  ’(uni-  (uni/  3.1415926536  2)  (get_ret_val))) 

(go  line_l) 

line_54  (exec  54)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (LT  (varval  varlist  ’(XO))  (varval  varlist  ’(BX)))))  (go  line_57)) 
(swln  (go  _t_switch))) 

line_55  (exec  55)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  argjist)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(VAR_REF  SA)  argjist)) 

(setq  arg_list  (reverse  arg_list)) 

(set_ret_val  (u_fabs  arg_list)) 

(cond  (_t_arglist  (setq  arg_list  J_arglist)  (setq  J_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(uni-  3.1415926536  (get_ret_val))) 

(go  line_l) 

line_57  ^exec  57)  (cond  (swln  (go  J_switch))) 

(cond  (argjist  (setq  J_arglist  argjist)  (setq  argjist  nil))) 
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(setq  arg_list  (cons  ’(VAR_REF  SA)  arg_list)) 

(setq  arg_list  (reverse  arg_list)) 

(set_ret_val  (u_fabs  arg_list)) 

(cond  (~t_arglist  (setq  arglist  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(uni-  (uni/  3.1415926536  2)  (get_ret_val))) 

(go  line_l) 

line_59  (exec  59)  (cond  (swln  (go  _t_switch))) 

;top  of  if 

(cond  ((not  (predval  (LE  (varval  varlist  ’(YO))  (varval  varlist  ’(CY)))))  (go  line_67)) 
(swln  (go  _t_switch))) 

line  60  (exec  60)  (cond  (swln  (go  J_switch))) 

;top  of  if 

(cond  ((not  (predval  (uni_EQ  (varval  varlist  ’(XO))  (varval  varlist  ’(DX)))))  (go  line_62)) 
(swln  (go  tswitch))) 

line_61  (exec  61)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  t  arglist  argjist)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(VAR_REF  SC)  arg  list)) 

(setq  argjist  (reverse  argjist)) 

(set  ret  val  (u  Jabs  arg  list)) 

(cond  (_t_arglist  (setq  arg  list  t  arglist)  (setq  J_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(uni-  (uni/  3.1415926536  2)  (get_ret_val))) 

(go  linej) 

line_62  (exec  62)  (cond  (swln  (go  J_switch))) 

;top  of  if 

(cond  ((not  (predval  (GT  (varval  varlist  ’(XO))  (varval  varlist  ’(CX)))))  (go  line_65)) 
(swln  (go  J  switch))) 

line_63  (exec  63)  (cond  (swln  (go  t_switch))) 

(cond  (argjist  (setq  J_arglist  argjist)  (setq  arg_list  nil))) 

(setq  arg  list  (cons  ’(VAR_REF  SD)  argjist)) 

(setq  argjist  (reverse  argjist)) 

(set  ret  val  (u  Jabs  arg  list)) 

(cond  (_t_arglist  (setq  argjist  J_arglist)  (setq  J_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(uni-  3.1415926536  (get_ret_val))) 

(go  linel) 

line_65  (exec  65)  (cond  (swln  (go  J_switch))) 

(cond  (arg_list  (setq  J_arglist  arg_list)  (setq  arg_list  nil))) 

(setq  argjist  (cons  ’(VAR_REF  SD)  argjist)) 
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(setq  arg_list  (reverse  arg_list)) 

(set_ret_val  (u_fabs  arg_list)) 

(cond  (_t_arglist  (setq  arg  Jist  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  argjist  nil))) 

(changevar  ’(Angle)  ’(uni-  (uni /  3.1415926536  2)  (get_ret_val))) 
(go  line_l) 

line_67  (exec  67)  (cond  (swln  (go  _t_switch))) 

(changevar  ’(Angle)  ’(uni*  2  3.1415926536)) 

(go  line_l) 

;end 

Angle.exit 

(do_exit_assertion)  (cond  (swln  (go  _t_switch))) 
(check_routine_exit)(cond  (swln  (go  _t_switch))) 

(setretval  ’(varval  varlist  ’(Angle))) 

(closeproc) 

(setq  swln  (car  temp)) 

(go  tswitch) 

getangle.main 

(savejnitvalues) 

(doentryassertion) 

(cond  (swln  (go  t  switch))) 

;begin 

line_70  (exec  70)  (cond  (swln  (go  _t_switch))) 

(cond  ((eq  (tyipeek)  NEWLINE)  (readc))) 

(unisex_read  ’(XO)) 

(unisexread  ’(YO)) 

(unisexread  ’(XT)) 

(unisex  read  ’(YT)) 

(unisex_read  ’(W)) 

(unisex  read  ’(L)) 

(cond  ((eq  (tyipeek)  NEWLINE)  (readc))) 
line_72  (exec  72)  (cond  (swln  (go  _t_switch))) 

(cond  (argjist  (setq  _t_arglist  arg_list)  (setq  argjist  nil))) 

(setq  arg_list  (cons  ’(VAR_REF  XO)  argjist)) 

(setq  arg_list  (cons  ’(VAR_REF  YO)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  XT)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  YT)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  W)  argjist)) 

(setq  argjist  (cons  ’(VAR_REF  L)  arg_list)) 

(setq  arg_list  (reverse  argjist)) 

(setq  routine_names  (cons  ’Angle  routine_names)) 
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(setq  proclist  (cons  ’f_ret_4  proclist)) 

(cond  (in_verif_mode  (setq  at_top_level  nil))) 

(go  Angle)  f_ret_4 

(cond  (_t_arglist  (setq  arg_list  _t_arglist)  (setq  _t_arglist  nil)) 

(t  (setq  arg_list  nil))) 

(changevar  ’(ang)  ’(get_ret_val)) 

line_73  (exec  73)  (cond  (swln  (go  _t_switch))) 

(unisex  write  "Observed  angle  is") 

(unisexwrite  (varval  varlist  ’(ang))) 

(terpri) 

(go  getangle.exit) 

;end 

getangle.exit 

(do  exit  assertion)  (cond  (swln  (go  _t_switch))) 

(exec  ’end)  (cond  (swln  (go  _t_switch)) 

(t  (return))) 

toplevelretum  (toplevelrestore)(go  _t_switch) 
t  switch  (setq  switch  swln)  (setq  swln  nil) 

(cond  ((or  (equal  switch  ’getangle)  (equal  _switch  "getangle"))  (go  getangle)) 

((or  (equal  switch  ’toplevelretum)  (equal  _switch  "toplevelretum"))  (go  toplevelretum)) 
((or  (equal  switch  ’Angle)  (equal  _switch  "Angle"))  (go  Angle)) 

((or  (equal  _switch  ’Angle. static_chain)  (equal  switch  "Angle.staticchain"))  (go 
Angle.  static_chain)) 

((or  (equal  _switch  ’Slope)  (equal  _switch  "Slope"))  (go  Slope)) 

((or  (equal  _switch  ’Slope. static_chain)  (equal  _switch  "Slope,  staticchain"))  (go 
Slope.  static_chain)) 

((or  (equal  switch  ’Slope,  main)  (equal  _switeh  "Slope,  main"))  (go  Slope,  main)) 

((or  (equal  _switch  ’line_10)  (equal  _switch  "line_10"))  (go  line_10)) 

((or  (equal  _switch  ’Slope.exit)  (equal  _switch  "Slope.exit"))  (go  Slope.exit)) 

((or  (equal  _switch  ’Angle.main)  (equal  _switch  "Angle. main"))  (go  Angle.main)) 

((or  (equal  _switch  ’line_13)  (equal  _switch  "line_13"))  (go  line_13)) 

((or  (equal  _switch  ’line_15)  (equal  _switch  "line_15"))  (go  line_15)) 

((or  (equal  _switch  ’line_16)  (equal  _switch  "line_16"))  (go  line_16)) 

((or  (equal  _switch  ’line_17)  (equal  _switch  "line_17"))  (go  line_17)) 

((or  (equal  switch  ’line_18)  (equal  _switch  "line_18"))  (go  line_18)) 

((or  (equal  _switch  ’line_19)  (equal  _switch  "line_19"))  (go  line_19)) 

((or  (equal  _switch  ’line_20)  (equal  _switch  "line_20"))  (go  line_20)) 

((or  (equal  _switch  ’line_21)  (equal  _switch  "line_21"))  (go  line_21)) 

((or  (equal  _switch  ’line_22)  (equal  _switch  "line_22"))  (go  line_22)) 

((or  (equal  _switch  ’line_23)  (equal  _switch  "line_23"))  (go  line_23)) 

((or  (equal  _switch  ’line_24)  (equal  _switch  "line_24"))  (go  line_24)) 

((or  (equal  _switch  ’f_ret_0)  (equal  _switch  "f_ret_0"))  (go  f_ret_0)) 

((or  (equal  _switch  ’line_25)  (equal  _switch  "line_25"))  (go  line_25)) 
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((or  (equal  _switch  ’line_26)  (equal  _switch  "line_26"))  (go  line_26)) 

((or  (equal  _switch  ’f_ret_l)  (equal  _switch  "f_ret_l"))  (go  f_ret_l)) 

((or  (equal  _switch  ’line_27)  (equal  switch  "line37"))  (go  Une_27» 

((or  (equal  _switch  ’line_28)  (equal  _switch  "line_28"))  (go  line_28)) 

((or  (equal  _switch  ’f_rel_2)  (equal  _switch  "f_re7_2"))  (go  f_ret_2)) 

((or  (equal  _switch  ’line_29)  (equal  _switch  "line_29"))  (go  line39)) 

((or  (equal  _switch  ’line_30)  (equal  _switch  "line_30"))  (go  line_30)) 

((or  (equal  _switch  ’f_rel_3)  (equal  _switch  "f_ret_3"))  (go  f_ret_3)) 

((or  (equal  _switch  ’line_31)  (equal  _switch  "Une3l"))  (go  line_31)) 

((or  (equal  _switch  ’line_32)  (equal  _switch  "line_32"))  (go  line_32)) 

((or  (equal  switch  ’line_33)  (equal  _switch  "line_33"))  (go  line_33)) 

((or  (equal  switch  ’line_l)  (equal  _switch  "line_l"))  (go  line_l» 

((or  (equal  _switch  ’line_35)  (equal  _switch  "line_35"))  (go  line_35)) 

((or  (equal  switch  ’line_36)  (equal  _switch  "line_36"))  (go  line_36)) 

((or  (equal  switch  ’line_38)  (equal  _switch  "line_38"))  (go  line_38)) 

((or  (equal  _switch  ’line_39)  (equal  _switch  "line_39"))  (go  line_39)) 

((or  (equal  switch  ’line_41)  (equal  _switch  "line_41"))  (go  line_41)) 

((or  (equal  switch  ’line_42)  (equal  _switch  "line_42"))  (go  line_42)) 

((or  (equal  switch  ’line_44)  (equal  _switch  "line_44"))  (go  line_44» 

((or  (equal  switch  ’line_45)  (equal  _switch  "line_45"))  (go  line_45)) 

((or  (equal  switch  ’line_47)  (equal  _switch  "line_47"))  (go  line_47)) 

((or  (equal  switch  ’line_48)  (equal  _switch  "line_48"»  (go  line_48)) 

((or  (equal  _switch  ’line_50)  (equal  _switch  “line_50")>  (go  line_50)) 

((or  (equal  switch  ’line_51)  (equal  _switch  "line_51"))  (go  line_51)) 

((or  (equal  _switch  ’line_52)  (equal  _switch  "line_52"))  (go  line_52)) 

((or  (equal  switch  ’line_54)  (equal  switch  "line_54"))  (go  line_54» 

((or  (equal  _switch  ’line_55)  (equal  _switch  "line_55"))  (go  line_55» 

((or  (equal  _switch  ’line_57)  (equal  _switch  "line_57"))  (go  line_57)) 

((or  (equal  _switch  ,line_59)  (equal  _switch  "line_59"»  (go  line_59)) 

((or  (equal  _switch  ’line_60)  (equal  _switch  ,,line_60"))  (go  line_60)) 

((or  (equal  _switch  ’line_61)  (equal  _switch  "line_6r»  (go  line_61)) 

((or  (equal  switch  ’line_62)  (equal  _switch  "line_62"))  (go  line_62)) 

((or  (equal  switch  ’line_63)  (equal  _switch  "line_63"))  (go  line_63)) 

((or  (equal  _switch  ’line_65)  (equal  _switch  "line_65"))  (go  line_65)) 

((or  (equal  _switch  ’line_67)  (equal  _switch  "line_67"))  (go  line_6^) 

((or  (equal  _switch  ’Angle.exit)  (equal  _switch  "Angle.exit"))  (go  Angle.exit)) 

((or  (equal  _switch  ’getangle.main)  (equal  _switch  "getangle.main"))  (go  getangle.main)) 
((or  (equal  _switch  ’line_70)  (equal  _switch  *line_70"))  (go  line30)) 

((or  (equal  _switch  ’line_72)  (equal  _switch  "line_72"))  (go  line_72)) 

((or  (equal  _switch  ’f_ret_4)  (equal  _switch  "f_reT_4"))  (go  f_reT_4» 

((or  (equal  _switch  ’line33)  (equal  _switch  "line33"))  (go  Une_73)) 

((or  (equal  _switch  ’getangle.exit)  (equal  _switch  "getangle.exit"))  (go  getangle.exit)) 

(t  (print  "can’t  find  target  for  goto") 
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(print  _t_switch) 

(teipri))) 

) 

) 

(setq  all  routines  (list  ’getangle  ’Angle  ’Slope)) 
(setq  NO_REALS  nil) 
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